We are in constant contanct (and infected by) millions of organisms every singal day. I've made it through life this far co-habitating, I don't think I'm going to worry about this much.
Um, yes. The biggest security risk is always the user.
"The kernel and most userland software is specifically designed with security in mind and they deliberately try to make it quite hard (ideally, impossible) to get unauthorized root access remotely."
Message to Joe Sixpack: You need to be root to install this software.
"New security-related bugs are found in Windows and Windows software every day."
So how many hackers are out there trying to break into linux systems? How many do you think I trying to break into windows systems. Now, just out of sheer odds, which group do you think is going to find the most exploits the quickest?
And as far as I can tell, new linux security issues seem to come up regualarly as well.
"(Partly due to the fact that almost every program that runs as the administrator.)"
And mostly due to user ignorance. Joe Sixpack does not want to be inconvenienced, and can't be bothered with this whole "Administrator" business. Joe Sixpack doesn't want to su, or manage config scripts, or have several passwords. For Joe Sixpack, that is just way too much. Joe Sixpack wants to surf the web, play his games, watch his movies, and messenger/email his friends.
That is what the vast majority of Windows users are. They want it fast, simple, and with as little learning as possible. That's why malware is such a huge issue.
"Our only hope is to rely on (third-party) firewalls, anti-spyware apps, and anti-virus apps, all of which treat the symptoms rather than the illness."
NAT router, spyware doesn't need admin priviliges, anti-virus is a necessity even on linux, and the illness is lack of education about computers.
"So, while OSS and Windows vulnerabilities might be roughly equal in number, it would be difficult to argue that they are anywhere near equal in severity."
No, they're not equal. There's a boatload more Joe Sixpacks on Windows than Linux, which makes Windows a lot more vulnerable.
"The statistic that Windows has 95% of the desktop market but attracts 99.9% of malware has always seemed a little odd to me."
Seems perfectly logical to me. Large installed base of fairly clueless users, prime target right there. Not to mention if you want your little piece of malware to spread to as many machines as possible, you target the machines that make up the majority.
"Windows with the majority of the malware because it's a lot less challenging to slip a virus or spyware program onto a Windows machine than an open source one."
I agree. Joe Sixpack Email: "Want to see Natalie Portman Naked? Just Install this!!!!!WOOT!!!"
"The moral of the story here is that Windows has the lion's share of malware perhaps not so much because it's a bigger target, but because it's simply an easier target."
I fully agree, but it's not an easier target because of exploits. It's an easier target because of it's user base.
I've been running windows systems for some time now, and I've rarely had issues with crashes, and have never been infected with viruses, malware, or spyware.
Why?
Because I know what the hell I'm doing. With linux even the novices have more of a clue about computer operations than your average Windows user.
What if linux had 95% of the market share? How long would it take for Joe Sixpack to become annoyed with su'ing to install software and just run as root all the time? Kaboom. You don't need exploit when you have Joe Sixpack.
It has little to do with system architecture, exploits, or holes. The biggest security risk has and will always be the people operating the machine.
Raise your beers and toast to Joe Sixpack, super user.
"Viruses/spyware and/or anti-virus/spyware software continually slow it down."
Hmmm...if I was a malware writter and wanted to get the most notoriety/most computers/most money would I target:
A. The operating system 95% of the world uses B. The operating system that 3% of the world uses C. The operating system that 2% of the world uses.
This is a real tough choice.
This arguement always gets under my skin. It's not that I'm a big fan of Microsoft, but you have to look at the situation logistically. If you're going to target computer systems for Evil purposes, you're going to target the system that has the most (inexperienced) users.
And since they're plenty of Bad people out there, they pool their resources and figure out ways to do this.
I can guarantee that if Linux were on 95% of computers in the world, it would be having the same malware and security issues as MS, mainly do to (inexperinced) users.
It's not really that linux is more secure, it's that the malware crowd really doesn't care about other OS's.
"and all that Microsoft seems to do lately is copy the innovative things that its rivals do"
Are what it's rivals doing good? Do people like what their rivals are doing? Yes? Then would it not be a good business decision to try and emulate your rivals?
I wonder if Archy was aware of the concept of equatorial mounting? If so, mounting a large mirror (or bunch of mirrors by pulleys) would have been easier to control and tracking much simpler.
~X~
How the code gets treated depends on how "clear" it is to the compiler. The loop in the example is simple and any decent optimizing compiler worth it's 1's and 0's should optimize it.
But if the code is unclear, let's say multiple nested loops with a good number of branches, local variables, etc. then an optimizing compiler will probably say WTF and just leave it alone.
As has been said many times, profile your code. If you find the bottle-neck, fix it. If it comes down to pointer vs. array, get rid of th array.
"For example, if you've a sequence of characters, and want to copy them, then copying them a character at a time - regardless of how - is slow and inefficient on a 32-bit or 64-bit machine. Cast the data onto the largest unit the CPU can pull out of memory in one operation, and operate in bulk/parallel."
Careful with that. If you're doing cross architecture code you'll have to keep in mind big-endian vs. little-endian.
In other news, the military has also created an anti-riot weapon that effectively controls crowds, but incinerates anything made of wood within a 1/4 mile radius.
"Seems to me that JOP is a processor defined in HDL."
Yep.
"It has a native instruction set consiting of bytecode instructions. It has a simpler underlying microcode that is used to handle the more complex bytecode instructions."
Yep.
"The fact that it is currently being run on a FPGA is niether here nor there."
I was just pointing out that the JOP is an FPGA, not a traditional ASIC CPU. That's all. The other processors you named are indeed native java machines, in the traditional sense.
"You seem to be implying that java bytecode ceases to be bytecode when you run it on a java processor, but is bytecode when you run it in a virtual machine. Its the same stuff, it hasn't changed."
The bytecode has not changed, but how it's executed has. When I hear "bytecode", I think interpereted. When I hear "opcode", I think executed. On a PC, bytecode is interpereted into opcodes that execute. On a java processor, java opcodes execute.
But this is the stuff of flame wars.
"Does code compiled for the motoroller 68k instruction set suddenly become bytecode when you try to run it in mame? does it somehow change?"
No, since it's being run through an emulator. But then again, how is an emulator different from a virtual machine? An emulator emulates existing hardware, while the Java VM IS it's hardware. Though it can easily be said that a PC is emulating the VM.
Not so clear cut anymore.
"Does code compiled for a x86 processor run natively? Considering most x86 processors emulate (albeit in hardware) the x86 instruction set on top of a "risc"ish core the definitions become ambiguous."
One of my peeves with the x86 family. You can't write any lower than the instruction set of the cpu, so for all intents and purposes it is "native". What the cpu does beyond that point is beyond your control. Though strictly speaking, the x86 is a "higher level" language sitting on top of a risc-like core.
With jave on "native" cores, it does get more difficult to find clear cut definitions. The shades of gray win again.:)
"Anyway it interests me. The whole concept of processors with direct support for high level languages. The lack of pointers in java mean that many of the reasons you would normally have a mmu for cease to exist (in smaller systems anyway) ( you can't bugger up memory that does not belong to you). The garbage collector can allocate all avaialble memory on the system and manage it efficiently. Some nice ideas, especially for embedded systems."
For smaller systems, yes I'd agree that an MMU is redundant. However for larger complex systems, I'd recommend having one. Or at least, having one you can switch to in case you need to optimize memry usage better than a general purpose GC.
Yep. I was wrong on that, but I've been out of the J2ME scene for awhile and haven't been keeping pace with the new developements.
There are indeed native java processors. In this case though, I think the terms bytecode and virtual machine should not be used as that is misleading. In these cases, java produces machine opcodes for the CPU, like any other compiled language.
"What? you mean Gcc starts emulating instructions that if implimented in hardware would give you far greater performance? (before you say it. Yes it does. it is EMULATING behaviour that does not exist natively.)"
Correct. If you do a 16-bit division and the processor does not support it, then the compiler will produce a series of opcodes to replicate the behavior. But this sort of thing only happens if the compiler target CPU does not have native opcodes for an operation.
"The 8 bit micro has top provide a development environment that supports 32 bit math whether emulated or not."
How is this different from C? The only real difference is that in C if you don't want to use it, you can cut it out entirely.
"For example I am currently playing around with JOP http://www.jopdesign.com/ This is a processor whose native instruction set is java byte code."
Well, kind of. The JOP is an FPGA, so its only real native instrcutions are in the HDL. The JOP processor could be reprogrammed to emulate just about any architecture you wanted it to. FPGAs are cool, but they do have their drawbacks such as higher power consumption and slower than their ASIC counterparts, but that's another subject.
"Unless C can compile code to JBC then it would have to run in an emulation layer on this processor (I have yet to see a c compiler that can produce java byte code. It Could be done I just have not seen it yet)"
I have seen several discussions on this, and as yet no one really thinks it's a worthwhile endeavor. The geek factor is pretty high, but it wouldn't serve any useful purpose. The closest thing that exists to this C# and managed C++ in.NET. But those target their own VM.
I'd like to see it anyway.:)
Regardless, since the FPGA is reprogrammable there would be no need to compile to the java bytecode. It might be just as effective to write a new HDL for the FPGA and have it run like whatever your original target CPU was.
"No they are not. Bytecode is machine code for a "java virtual machine"."
I'm going to disagree on your terminology. The term opcode has always been used to define a native CPU instruction. Bytecode is a virtual machine instruction. Mixing the two can be misleading.
"C and java require a "virtual machine" in the same way. However Java targets one architecutre (java byte code) and C targets many (any instruction set that can be targeted by your compiler)."
I'm going to disagree here as well. The term virtual machine just simply does not apply to native compiled languages, as there is nothing virtual about the hardware to which you are compiling to. Java does compile to a virtual machine, as for the most part there aren't many machines out there that support Java natively.
"Jop, Cjip, aJ-100, are all processors that run bytecode natively. Even sun produced one back in 95 (cant remeber the name but it was a hacked up sparc)"
You are correct. The JOP is an FPGA but the AJ-100 and CJIP are ASICS that do have java opcodes. But in these cases, there is no longer a virtual machine or bytecode for that matter. You have java being compiled down to native machine architecture and instructions. The terms of virtual machine and bytcode no longer apply, IMHO.
"And when resources get really tight C is no longer an appropriate language to use."
Indeed.
"C also has to be cut down to run on these low end devices. floating point divisions, 32 bit mulitplications, 16 bit additions...well they are not supported."
That's misleading at best.
That has nothing to do with the language, and everything to do with the compiler and linker for the platform. In the end, you wind up with native CPU instructions. If the processor supports flops, then the compiler/linker will use flops. If the processor does not, then it will use whatever algorithm to replace the flop code with. That's the whole purpose of cross compilers such as gcc. It takes C code and compiles it for a given platform. If the platform doesn't support certain operations then those operations are replaced at compile time with whatever the platform needs to approximate/implement said feature.
"The J2ME IS cut down. However it does specify a basic set of operations you must implement on the chip (or emulate in a layer in software)"
I'm well aware of the fact that J2ME is cut down. I've written several games in J2ME. But you seem to be a little confused. J2ME has a bytcode spec, and several chip manufacturers follow the spec for J2ME microcontrollers but that is not native execution. The translation from bytcode to CPU instructions happens in hardware, which is fast to be sure but still is not native CPU code.
"The processors I'm playing with at the moment run java byte code natively."
No they don't. They have a "hardware JVM" for lack of a better term. The CPU is not running bytecode. None of the processor families I found doing a quick search have a J2ME bytcode based instruction set. Underneath, they are still running ARM, Fujitsu, etc. chips, which use their normal CPU instructions to execute.
"You would have to have a virtual machine to run C on them."
At first, I thought you were merely confused. Now it appears you don't know what you are talking about. C is compiled. Period. If you have a processor with instruction set A and you have a C compiler for that processor, after the program is compiled you have binary code consisting of instruction set A operands. C is not interpereted. C is not JIT. After compilation, you have a raw binary executable which will run on that processor.
"Rememeber, C is only efficient in some situations because the bytecode (machine code) it produces maps directly to the platform it is running on."
C is always "mapped" to the machine's native instruction set.
Let's see if I can clear this up for you.
Java, when compiled, produces bytecode. You know this. When you want to run a java program, you must have a JVM. You know this as well. The JVM takes the bytecode and translates this into the machines native CPU instructions. That translation happens at run-time. I think you know this. On PCs, the JVM is software, so the translation all happens in software.
C, when compiled, produces native machine CPU instructions. That's it. There is no translation at run-time. There is no virtual machine. There is no bytecode. A compiled C program is a native executable.
Bytecode and machine code are two different things.
Bytecode allows for one to have portable compiled programs. For instance, you can take a compiled java program, bring it onto a machine of completely different architecture, and have it run as long as there is a JVM installed on that machine.
If you try to take a C executable and bring it onto a machine of completely different architecture, it won't run at all. The only way to get the program to run is to take the original source, recompile it on the new machine, and then run the program.
J2ME microcontrollers take the JVM one step further by taking a set of java bytecode instructions and embedding the translation to machine code in hardware. This results in a much faster JVM performance than the slower software JVMs found on general purpose computers. But there is still
"Try writing a Java program that eats less than 32k." "No problem at all. (link)"
Hmmmm......
First, lets compare apples to apples. J2ME was not designed to write programs for PCs. That's what Java is for. J2ME was written for embedded/limited systems.
That being said, you still can't write a Java program that uses less than 32 KB. And that info comes straight from your link.
#Reduced VM Size - the K virtual machine is currently only 50-80 K of object code in its standard #configuration, depending on target platform and compilation options.
Alright, you already have 50-80K gone. There goes that 32KB limit.
# Reduced Memory utilization - In addition to the K virtual machine's small object size, it requires #only a few tens of kilobytes of dynamic memory to run effectively. Because of the reduced VM size and #memory utilization, even with total memory available of only 128K the K virtual machine enables useful #Java technology-based applications to run on a device.
I gather from this, you'll need about 128KB of memory.
And you haven't written a single line of code yet.
Plus, it seems you need to have at least a semi-powerful CPU to run the thing (25MHz 16-bit is the example from the link).
Now as a comparison, I've written apps and even whole games in 32KB or less on PCs and limited systems. The original gameboy, for example, had a 1.05MHz processor 4KB dedicated RAM (with another 7 banks of switchable 4KB blocks). The processor was a stripped down Z80 CPU.
Java has it's place, along with J2ME. But it's not in writing tight fast code when system resources are limited or in situations where every cycle of performance matters.
Remember, with Java you still have the overhead of a virtual machine. And that counts towards program and resource size (sometimes, significantly).
This kid is a green programmer bitching about his first job.
Even if he was a very bright programmer, he is still worth far less than a seasoned software engineer.
I don't believe anyone is saying he can't reach for what he wants. They're saying he is incredibly naive if he is expecting it being fresh out of college.
This article sounds more like the real world smacking this idiot in the face and waking him from his daydream of fame and fortune.
Here are the lessons this kid needs to learn:
1. The real world doesn't owe you jack.
It never ceases to amaze me how many fresh college grad expect the world to beat a path to their door with 6 figures, a company car, and a trophy wife. More like low 5 figures, you buy your own car, and regret every morning when the beer goggles wear off.
You start at the bottom and work your way up. It's a long ladder, there are people ahead of you, and some will do really craptastical things to stay on their rung (and prevent you from climbing). That's life.
2. The real world operates on costs and profits.
A business is there to generate profit and minimize cost. Anything it does for it's employees is either mandated by law or is done so it can compete in the job market. If a company does do some additional perks, count yourself very lucky. But the minute your cost-to-profit ratio starts slipping, you can bet a private meeting with your line manager is in the cards.
This leads to....
3. You are not special, you are expendable.
If you've got ego, you better keep it in check. There are a few thousand green programmers out there that can be hired for less and may even do a better job.
You can and will be removed and/or replaced on a whim if the company determines it will increase profitability or lower costs.
You need to make sure your value to the company outweighs the cost. But sometimes shit happens (or PHBs) and despite your best efforts you get canned anyway.
You can always try for greener pastures....
4. You can leave.
You can hit the road if you don't like it. But you'd better be ready to handle unemployment. And when you leave....
5. You do not burn bridges.
Yet another mistake I see novices make. If your going to leave, leave professionally. At the exit interview, be honest about the reasons you're leaving but keep it clean. This industry is smaller than you think and you never know who you're going to cross paths with (or what position they may hold).
"Besides it's no fun how can you have nerf wars in offices?"
Better make damn sure you know who your working for before you pull that crap. The last thing you need to do is give your higher ups reasons to kick your ass out the door.
There were 160 of us working in a shoebox in the middle of the road. We had to share a single dumb terminal, work 80 hours a week. And when we were done for the day, the manager would come by and lash us with his belt!
But you try and tell the young people of today that, and they won't believe you.
You are correct in that God never orders a rape, however it is laid out in Deuteronomy (don't remember where, but someone mentioned it in this thread) on the rules you follow for condoned rape after conquering your enemy.
"Sin (lack of doing what is completely and entirely right) must be punished.God's mercy causes Him to defer punishment, but His justice demands that sin be punished."
This depends on who or what is defining what "right" is. What is right has and is defined differently from culture to culture and from religion to religion.
For instance, pornography is pretty much abhored by the religious in this country but there are hundreds of tribes and cultures that go around practically nude and have fertility "orgies". Are they sinners that should be punished because they've never heard of your God?
What about the aztecs or the mayans. What about the greeks and romans? What about the millions of people that have existsed and do exist that have never heard of your God. Should they be judged by your rules? And if so, what makes your rules so much better than theirs? Why after thousands of years should they change just because you think your religion is better than theirs?
Every culture has a concept of right and wrong. Just because it goes against your God and your beliefs does not make them evil, or anymore deserving of punishment than you.
"While He is benevolent, 'it is a fearful thing to fall into the hands of the living God.'"
A benevolent God would not make you live in guilt and fear for your whole damn life. At best this is inconsistent.
"I'm curious: Is it your assertion that it is wrong for God to say that killing and taking the goods of those killed is ok?"
Yes, according to the oft portrayed "loving God" that I see and hear people represent.
"On what do you base that assertion?"
Church, TV, internet, and religious friends.
If murder is a sin, then it should be sin all the time. Killing someone in the name of any diety just because they don't believe in your diety is just plain stupid.
Believing your religion is the one true religion and everyone else that does not follow your religion is an evil heathen that deserves to die is just as stupid.
Judging the world and it's cultures based on the narrow, ego-centric view of one religious text from x thousand years ago that is full of it's own hypocrisy and double standards is completely fucking idiotic.
The world and it's people existed long before the bible and will exist long after it is relegated to a dead religion. The sooner these religions that are filled with inane hate and prejudice die, the better off the rest of humanity will be.
"And it makes sense now: Home/Family learned violence + Videogame-learned violent actions = dangerous person."
No, it doesn't make sense. Why? Because out of the millions who play violent video games, a very very very small percentage do anything psychotic. Even with kids in broken homes.
The real math here is:
Home/Family learned violence + unstable mental state = dangerous person.
Problems at home have a vastly greater influence on a developing psyche than any video game. I've played violent video games for a good portion of my life and I still don't have an automatic response to run down a hooker with my car. Nor do I have propensity for pumping myself full of narcotics and go on a shooting spree.
When people lose their ability to discern right from wrong (or cease to care), that's when the problems begin. And that comes long before any video game influence.
Considering the millions that do play violent video games, one has to wonder why crime is at a 30 year low.
"You don't have to agree with what God ordered them to do, but there's no direct contradiction between Exodus 20:13 and God's orders to His people."
Except that the all-powerful, omniscient, benevolent God is endorsing killing, pillaging, and raping.
But other than that there's no contradiction at all.
~X~
Re:What about the Constitution?
on
Sorry, Wrong Wiretap
·
· Score: 2, Insightful
Hmmm...what was that? Something about the constitution? Wasn't that like a boat or something in the civil war?
Most people in the US would rather wipe their ass with it than try to read and comprehend it.
And then the people elect officials with the same view. Over the past few years "We The People..." have sat idly by as all those flag wavers in raped and pillaged the founding document of this country.
We let them do it. We encouraged them to do it. And some seem so shocked when they hear about it.
"The commies failed because even though they killed a lot of people, it was not necessarily the people they wanted to get."
Ugh! For cryin' out loud, how do comments like this get modded insightful?
They weren't "commies". Communism had little to do with their government, let alone killing millions of people.
Communism is what could be considered the utopia government. Everyone works together and contributes to the whole, and everyone gets an equal and fair share.
But as has been shown in the past, the shiny happy cumbaya governments always fail or turn into something ugly due to the faults in human nature. People get greedy, and things fall apart from there.
All the "communist" regimes I know of (I could be missing some) are more authoratarian or fascist in nature. They claim to be communist but they aren't.
Slashdot Mirror
One word: PARANOIA.
We are in constant contanct (and infected by) millions of organisms every singal day. I've made it through life this far co-habitating, I don't think I'm going to worry about this much.
Nothing to see here, move along....
~X~
My freaking' brain has just been orafucked by that link. Oh where is the number to my therapist. :P
~X~
"Um, no."
Um, yes. The biggest security risk is always the user.
"The kernel and most userland software is specifically designed with security in mind and they deliberately try to make it quite hard (ideally, impossible) to get unauthorized root access remotely."
Message to Joe Sixpack: You need to be root to install this software.
"New security-related bugs are found in Windows and Windows software every day."
So how many hackers are out there trying to break into linux systems? How many do you think I trying to break into windows systems. Now, just out of sheer odds, which group do you think is going to find the most exploits the quickest?
And as far as I can tell, new linux security issues seem to come up regualarly as well.
"(Partly due to the fact that almost every program that runs as the administrator.)"
And mostly due to user ignorance. Joe Sixpack does not want to be inconvenienced, and can't be bothered with this whole "Administrator" business. Joe Sixpack doesn't want to su, or manage config scripts, or have several passwords. For Joe Sixpack, that is just way too much. Joe Sixpack wants to surf the web, play his games, watch his movies, and messenger/email his friends.
That is what the vast majority of Windows users are. They want it fast, simple, and with as little learning as possible. That's why malware is such a huge issue.
"Our only hope is to rely on (third-party) firewalls, anti-spyware apps, and anti-virus apps, all of which treat the symptoms rather than the illness."
NAT router, spyware doesn't need admin priviliges, anti-virus is a necessity even on linux, and the illness is lack of education about computers.
"So, while OSS and Windows vulnerabilities might be roughly equal in number, it would be difficult to argue that they are anywhere near equal in severity."
No, they're not equal. There's a boatload more Joe Sixpacks on Windows than Linux, which makes Windows a lot more vulnerable.
"The statistic that Windows has 95% of the desktop market but attracts 99.9% of malware has always seemed a little odd to me."
Seems perfectly logical to me. Large installed base of fairly clueless users, prime target right there. Not to mention if you want your little piece of malware to spread to as many machines as possible, you target the machines that make up the majority.
"Windows with the majority of the malware because it's a lot less challenging to slip a virus or spyware program onto a Windows machine than an open source one."
I agree. Joe Sixpack Email: "Want to see Natalie Portman Naked? Just Install this!!!!!WOOT!!!"
"The moral of the story here is that Windows has the lion's share of malware perhaps not so much because it's a bigger target, but because it's simply an easier target."
I fully agree, but it's not an easier target because of exploits. It's an easier target because of it's user base.
I've been running windows systems for some time now, and I've rarely had issues with crashes, and have never been infected with viruses, malware, or spyware.
Why?
Because I know what the hell I'm doing. With linux even the novices have more of a clue about computer operations than your average Windows user.
What if linux had 95% of the market share? How long would it take for Joe Sixpack to become annoyed with su'ing to install software and just run as root all the time? Kaboom. You don't need exploit when you have Joe Sixpack.
It has little to do with system architecture, exploits, or holes. The biggest security risk has and will always be the people operating the machine.
Raise your beers and toast to Joe Sixpack, super user.
~X~
Stupid and short-sighted? Tell me, does the government work any other way?
~X~
"Viruses/spyware and/or anti-virus/spyware software continually slow it down."
Hmmm...if I was a malware writter and wanted to get the most notoriety/most computers/most money would I target:
A. The operating system 95% of the world uses
B. The operating system that 3% of the world uses
C. The operating system that 2% of the world uses.
This is a real tough choice.
This arguement always gets under my skin. It's not that I'm a big fan of Microsoft, but you have to look at the situation logistically. If you're going to target computer systems for Evil purposes, you're going to target the system that has the most (inexperienced) users.
And since they're plenty of Bad people out there, they pool their resources and figure out ways to do this.
I can guarantee that if Linux were on 95% of computers in the world, it would be having the same malware and security issues as MS, mainly do to (inexperinced) users.
It's not really that linux is more secure, it's that the malware crowd really doesn't care about other OS's.
"and all that Microsoft seems to do lately is copy the innovative things that its rivals do"
Are what it's rivals doing good? Do people like what their rivals are doing? Yes? Then would it not be a good business decision to try and emulate your rivals?
~X~
I wonder if Archy was aware of the concept of equatorial mounting? If so, mounting a large mirror (or bunch of mirrors by pulleys) would have been easier to control and tracking much simpler. ~X~
How the code gets treated depends on how "clear" it is to the compiler. The loop in the example is simple and any decent optimizing compiler worth it's 1's and 0's should optimize it.
But if the code is unclear, let's say multiple nested loops with a good number of branches, local variables, etc. then an optimizing compiler will probably say WTF and just leave it alone.
As has been said many times, profile your code. If you find the bottle-neck, fix it. If it comes down to pointer vs. array, get rid of th array.
"For example, if you've a sequence of characters, and want to copy them, then copying them a character at a time - regardless of how - is slow and inefficient on a 32-bit or 64-bit machine. Cast the data onto the largest unit the CPU can pull out of memory in one operation, and operate in bulk/parallel."
Careful with that. If you're doing cross architecture code you'll have to keep in mind big-endian vs. little-endian.
~X~
In other news, the military has also created an anti-riot weapon that effectively controls crowds, but incinerates anything made of wood within a 1/4 mile radius.
~X~
"Seems to me that JOP is a processor defined in HDL."
:)
Yep.
"It has a native instruction set consiting of bytecode instructions. It has a simpler underlying microcode that is used to handle the more complex bytecode instructions."
Yep.
"The fact that it is currently being run on a FPGA is niether here nor there."
I was just pointing out that the JOP is an FPGA, not a traditional ASIC CPU. That's all. The other processors you named are indeed native java machines, in the traditional sense.
"You seem to be implying that java bytecode ceases to be bytecode when you run it on a java processor, but is bytecode when you run it in a virtual machine. Its the same stuff, it hasn't changed."
The bytecode has not changed, but how it's executed has. When I hear "bytecode", I think interpereted. When I hear "opcode", I think executed. On a PC, bytecode is interpereted into opcodes that execute. On a java processor, java opcodes execute.
But this is the stuff of flame wars.
"Does code compiled for the motoroller 68k instruction set suddenly become bytecode when you try to run it in mame? does it somehow change?"
No, since it's being run through an emulator. But then again, how is an emulator different from a virtual machine? An emulator emulates existing hardware, while the Java VM IS it's hardware. Though it can easily be said that a PC is emulating the VM.
Not so clear cut anymore.
"Does code compiled for a x86 processor run natively? Considering most x86 processors emulate (albeit in hardware) the x86 instruction set on top of a "risc"ish core the definitions become ambiguous."
One of my peeves with the x86 family. You can't write any lower than the instruction set of the cpu, so for all intents and purposes it is "native". What the cpu does beyond that point is beyond your control. Though strictly speaking, the x86 is a "higher level" language sitting on top of a risc-like core.
With jave on "native" cores, it does get more difficult to find clear cut definitions. The shades of gray win again.
"Anyway it interests me. The whole concept of processors with direct support for high level languages. The lack of pointers in java mean that many of the reasons you would normally have a mmu for cease to exist (in smaller systems anyway) ( you can't bugger up memory that does not belong to you). The garbage collector can allocate all avaialble memory on the system and manage it efficiently. Some nice ideas, especially for embedded systems."
For smaller systems, yes I'd agree that an MMU is redundant. However for larger complex systems, I'd recommend having one. Or at least, having one you can switch to in case you need to optimize memry usage better than a general purpose GC.
~X~
Yep. I was wrong on that, but I've been out of the J2ME scene for awhile and haven't been keeping pace with the new developements.
There are indeed native java processors. In this case though, I think the terms bytecode and virtual machine should not be used as that is misleading. In these cases, java produces machine opcodes for the CPU, like any other compiled language.
~X~
"What? you mean Gcc starts emulating instructions that if implimented in hardware would give you far greater performance? (before you say it. Yes it does. it is EMULATING behaviour that does not exist natively.)"
.NET. But those target their own VM.
:)
Correct. If you do a 16-bit division and the processor does not support it, then the compiler will produce a series of opcodes to replicate the behavior. But this sort of thing only happens if the compiler target CPU does not have native opcodes for an operation.
"The 8 bit micro has top provide a development environment that supports 32 bit math whether emulated or not."
How is this different from C? The only real difference is that in C if you don't want to use it, you can cut it out entirely.
"For example I am currently playing around with JOP http://www.jopdesign.com/ This is a processor whose native instruction set is java byte code."
Well, kind of. The JOP is an FPGA, so its only real native instrcutions are in the HDL. The JOP processor could be reprogrammed to emulate just about any architecture you wanted it to. FPGAs are cool, but they do have their drawbacks such as higher power consumption and slower than their ASIC counterparts, but that's another subject.
"Unless C can compile code to JBC then it would have to run in an emulation layer on this processor (I have yet to see a c compiler that can produce java byte code. It Could be done I just have not seen it yet)"
I have seen several discussions on this, and as yet no one really thinks it's a worthwhile endeavor. The geek factor is pretty high, but it wouldn't serve any useful purpose. The closest thing that exists to this C# and managed C++ in
I'd like to see it anyway.
Regardless, since the FPGA is reprogrammable there would be no need to compile to the java bytecode. It might be just as effective to write a new HDL for the FPGA and have it run like whatever your original target CPU was.
"No they are not. Bytecode is machine code for a "java virtual machine"."
I'm going to disagree on your terminology. The term opcode has always been used to define a native CPU instruction. Bytecode is a virtual machine instruction. Mixing the two can be misleading.
"C and java require a "virtual machine" in the same way. However Java targets one architecutre (java byte code) and C targets many (any instruction set that can be targeted by your compiler)."
I'm going to disagree here as well. The term virtual machine just simply does not apply to native compiled languages, as there is nothing virtual about the hardware to which you are compiling to. Java does compile to a virtual machine, as for the most part there aren't many machines out there that support Java natively.
"Jop, Cjip, aJ-100, are all processors that run bytecode natively. Even sun produced one back in 95 (cant remeber the name but it was a hacked up sparc)"
You are correct. The JOP is an FPGA but the AJ-100 and CJIP are ASICS that do have java opcodes. But in these cases, there is no longer a virtual machine or bytecode for that matter. You have java being compiled down to native machine architecture and instructions. The terms of virtual machine and bytcode no longer apply, IMHO.
~X~
"And when resources get really tight C is no longer an appropriate language to use."
Indeed.
"C also has to be cut down to run on these low end devices. floating point divisions, 32 bit mulitplications, 16 bit additions...well they are not supported."
That's misleading at best.
That has nothing to do with the language, and everything to do with the compiler and linker for the platform. In the end, you wind up with native CPU instructions. If the processor supports flops, then the compiler/linker will use flops. If the processor does not, then it will use whatever algorithm to replace the flop code with. That's the whole purpose of cross compilers such as gcc. It takes C code and compiles it for a given platform. If the platform doesn't support certain operations then those operations are replaced at compile time with whatever the platform needs to approximate/implement said feature.
"The J2ME IS cut down. However it does specify a basic set of operations you must implement on the chip (or emulate in a layer in software)"
I'm well aware of the fact that J2ME is cut down. I've written several games in J2ME. But you seem to be a little confused. J2ME has a bytcode spec, and several chip manufacturers follow the spec for J2ME microcontrollers but that is not native execution. The translation from bytcode to CPU instructions happens in hardware, which is fast to be sure but still is not native CPU code.
"The processors I'm playing with at the moment run java byte code natively."
No they don't. They have a "hardware JVM" for lack of a better term. The CPU is not running bytecode. None of the processor families I found doing a quick search have a J2ME bytcode based instruction set. Underneath, they are still running ARM, Fujitsu, etc. chips, which use their normal CPU instructions to execute.
"You would have to have a virtual machine to run C on them."
At first, I thought you were merely confused. Now it appears you don't know what you are talking about. C is compiled. Period. If you have a processor with instruction set A and you have a C compiler for that processor, after the program is compiled you have binary code consisting of instruction set A operands. C is not interpereted. C is not JIT. After compilation, you have a raw binary executable which will run on that processor.
"Rememeber, C is only efficient in some situations because the bytecode (machine code) it produces maps directly to the platform it is running on."
C is always "mapped" to the machine's native instruction set.
Let's see if I can clear this up for you.
Java, when compiled, produces bytecode. You know this. When you want to run a java program, you must have a JVM. You know this as well. The JVM takes the bytecode and translates this into the machines native CPU instructions. That translation happens at run-time. I think you know this. On PCs, the JVM is software, so the translation all happens in software.
C, when compiled, produces native machine CPU instructions. That's it. There is no translation at run-time. There is no virtual machine. There is no bytecode. A compiled C program is a native executable.
Bytecode and machine code are two different things.
Bytecode allows for one to have portable compiled programs. For instance, you can take a compiled java program, bring it onto a machine of completely different architecture, and have it run as long as there is a JVM installed on that machine.
If you try to take a C executable and bring it onto a machine of completely different architecture, it won't run at all. The only way to get the program to run is to take the original source, recompile it on the new machine, and then run the program.
J2ME microcontrollers take the JVM one step further by taking a set of java bytecode instructions and embedding the translation to machine code in hardware. This results in a much faster JVM performance than the slower software JVMs found on general purpose computers. But there is still
"Try writing a Java program that eats less than 32k."
"No problem at all. (link)"
Hmmmm......
First, lets compare apples to apples. J2ME was not designed to write programs for PCs. That's what Java is for. J2ME was written for embedded/limited systems.
That being said, you still can't write a Java program that uses less than 32 KB. And that info comes straight from your link.
#Reduced VM Size - the K virtual machine is currently only 50-80 K of object code in its standard #configuration, depending on target platform and compilation options.
Alright, you already have 50-80K gone. There goes that 32KB limit.
# Reduced Memory utilization - In addition to the K virtual machine's small object size, it requires #only a few tens of kilobytes of dynamic memory to run effectively. Because of the reduced VM size and #memory utilization, even with total memory available of only 128K the K virtual machine enables useful #Java technology-based applications to run on a device.
I gather from this, you'll need about 128KB of memory.
And you haven't written a single line of code yet.
Plus, it seems you need to have at least a semi-powerful CPU to run the thing (25MHz 16-bit is the example from the link).
Now as a comparison, I've written apps and even whole games in 32KB or less on PCs and limited systems. The original gameboy, for example, had a 1.05MHz processor 4KB dedicated RAM (with another 7 banks of switchable 4KB blocks). The processor was a stripped down Z80 CPU.
Java has it's place, along with J2ME. But it's not in writing tight fast code when system resources are limited or in situations where every cycle of performance matters.
Remember, with Java you still have the overhead of a virtual machine. And that counts towards program and resource size (sometimes, significantly).
~X~
This kid is a green programmer bitching about his first job.
Even if he was a very bright programmer, he is still worth far less than a seasoned software engineer.
I don't believe anyone is saying he can't reach for what he wants. They're saying he is incredibly naive if he is expecting it being fresh out of college.
~X~
Tip #4:
....
Duck, you freakin' idiot!
~X~
Agreed.
This article sounds more like the real world smacking this idiot in the face and waking him from his daydream of fame and fortune.
Here are the lessons this kid needs to learn:
1. The real world doesn't owe you jack.
It never ceases to amaze me how many fresh college grad expect the world to beat a path to their door with 6 figures, a company car, and a trophy wife. More like low 5 figures, you buy your own car, and regret every morning when the beer goggles wear off.
You start at the bottom and work your way up. It's a long ladder, there are people ahead of you, and some will do really craptastical things to stay on their rung (and prevent you from climbing). That's life.
2. The real world operates on costs and profits.
A business is there to generate profit and minimize cost. Anything it does for it's employees is either mandated by law or is done so it can compete in the job market. If a company does do some additional perks, count yourself very lucky. But the minute your cost-to-profit ratio starts slipping, you can bet a private meeting with your line manager is in the cards.
This leads to....
3. You are not special, you are expendable.
If you've got ego, you better keep it in check. There are a few thousand green programmers out there that can be hired for less and may even do a better job.
You can and will be removed and/or replaced on a whim if the company determines it will increase profitability or lower costs.
You need to make sure your value to the company outweighs the cost. But sometimes shit happens (or PHBs) and despite your best efforts you get canned anyway.
You can always try for greener pastures....
4. You can leave.
You can hit the road if you don't like it. But you'd better be ready to handle unemployment. And when you leave....
5. You do not burn bridges.
Yet another mistake I see novices make. If your going to leave, leave professionally. At the exit interview, be honest about the reasons you're leaving but keep it clean. This industry is smaller than you think and you never know who you're going to cross paths with (or what position they may hold).
~X~
"Besides it's no fun how can you have nerf wars in offices?"
Better make damn sure you know who your working for before you pull that crap. The last thing you need to do is give your higher ups reasons to kick your ass out the door.
~X~
Luxury!
There were 160 of us working in a shoebox in the middle of the road. We had to share a single dumb terminal, work 80 hours a week. And when we were done for the day, the manager would come by and lash us with his belt!
But you try and tell the young people of today that, and they won't believe you.
~X~
Judge Dredd.
*ducks*
~X~
Me: "Man you gotta see that movie! It was @#$%ing great!"
You: "Tell me about it!"
Me: "Well there was....uh....and this...uh.....hmmmm...."
Announcer: "Amnesia DRM! All the flavor, none of the FAT!"
~X~
You are correct in that God never orders a rape, however it is laid out in Deuteronomy (don't remember where, but someone mentioned it in this thread) on the rules you follow for condoned rape after conquering your enemy.
"Sin (lack of doing what is completely and entirely right) must be punished.God's mercy causes Him to defer punishment, but His justice demands that sin be punished."
This depends on who or what is defining what "right" is. What is right has and is defined differently from culture to culture and from religion to religion.
For instance, pornography is pretty much abhored by the religious in this country but there are hundreds of tribes and cultures that go around practically nude and have fertility "orgies". Are they sinners that should be punished because they've never heard of your God?
What about the aztecs or the mayans. What about the greeks and romans? What about the millions of people that have existsed and do exist that have never heard of your God. Should they be judged by your rules? And if so, what makes your rules so much better than theirs? Why after thousands of years should they change just because you think your religion is better than theirs?
Every culture has a concept of right and wrong. Just because it goes against your God and your beliefs does not make them evil, or anymore deserving of punishment than you.
"While He is benevolent, 'it is a fearful thing to fall into the hands of the living God.'"
A benevolent God would not make you live in guilt and fear for your whole damn life. At best this is inconsistent.
"I'm curious: Is it your assertion that it is wrong for God to say that killing and taking the goods of those killed is ok?"
Yes, according to the oft portrayed "loving God" that I see and hear people represent.
"On what do you base that assertion?"
Church, TV, internet, and religious friends.
If murder is a sin, then it should be sin all the time. Killing someone in the name of any diety just because they don't believe in your diety is just plain stupid.
Believing your religion is the one true religion and everyone else that does not follow your religion is an evil heathen that deserves to die is just as stupid.
Judging the world and it's cultures based on the narrow, ego-centric view of one religious text from x thousand years ago that is full of it's own hypocrisy and double standards is completely fucking idiotic.
The world and it's people existed long before the bible and will exist long after it is relegated to a dead religion. The sooner these religions that are filled with inane hate and prejudice die, the better off the rest of humanity will be.
~X~
"And it makes sense now: Home/Family learned violence + Videogame-learned violent actions = dangerous person."
No, it doesn't make sense. Why? Because out of the millions who play violent video games, a very very very small percentage do anything psychotic. Even with kids in broken homes.
The real math here is:
Home/Family learned violence + unstable mental state = dangerous person.
Problems at home have a vastly greater influence on a developing psyche than any video game. I've played violent video games for a good portion of my life and I still don't have an automatic response to run down a hooker with my car. Nor do I have propensity for pumping myself full of narcotics and go on a shooting spree.
When people lose their ability to discern right from wrong (or cease to care), that's when the problems begin. And that comes long before any video game influence.
Considering the millions that do play violent video games, one has to wonder why crime is at a 30 year low.
~X~
"You don't have to agree with what God ordered them to do, but there's no direct contradiction between Exodus 20:13 and God's orders to His people."
Except that the all-powerful, omniscient, benevolent God is endorsing killing, pillaging, and raping.
But other than that there's no contradiction at all.
~X~
Hmmm...what was that? Something about the constitution? Wasn't that like a boat or something in the civil war?
Most people in the US would rather wipe their ass with it than try to read and comprehend it.
And then the people elect officials with the same view. Over the past few years "We The People..." have sat idly by as all those flag wavers in raped and pillaged the founding document of this country.
We let them do it. We encouraged them to do it. And some seem so shocked when they hear about it.
It's comedic and sad at the same time.
~X~
"The commies failed because even though they killed a lot of people, it was not necessarily the people they wanted to get."
Ugh! For cryin' out loud, how do comments like this get modded insightful?
They weren't "commies". Communism had little to do with their government, let alone killing millions of people.
Communism is what could be considered the utopia government. Everyone works together and contributes to the whole, and everyone gets an equal and fair share.
But as has been shown in the past, the shiny happy cumbaya governments always fail or turn into something ugly due to the faults in human nature. People get greedy, and things fall apart from there.
All the "communist" regimes I know of (I could be missing some) are more authoratarian or fascist in nature. They claim to be communist but they aren't.
~X~