With Jikes, you have a number of options, including obfuscation (which is just an algorithm to reduce code size -- smaller class & var names are used).
As I understand it, the obfuscation is only for protection of source code. Using the line number & local variable name tables, it is relatively easy to decompile code with a very high level of accuracy.
Obfuscation has relatively little impact on program size, and no impact on runtime speed. With the use of the constant pool, there is only one copy of any class name, variable name, etc. I guess the code size could have an impact when you are downloading applets. But then you should be putting stuff in a jar anyway. At runtime the longer names in the code have no impact. Even in the earliest interpreting VM from Sun, the first time a method is called / field is accessed, the code modifies itself to replace the call/access instruction with a fast version. Once you take into account the 90/10 rule....
I could be wrong. It has been known to happen occasionally:-)
IDE's like JBuilder may actually have their use, if you just want to quickly make GUI's and concentrate on code internals. It deals with most of the Swing/AWT for you. Available on Linux. Automates some things for bad codewriters you might work with, to cut down on bugs.
I don't use IDEs - so the following is pretty uninformed. But the slowest and most convualuted piece of code that I have ever seen came from a Java IDE. (I think VisualAge was too blame.) It actually used
Class.forName("...").newInstance(...);
to create instances of other classes also produced by the IDE - it was as if the programmers didn't know the 'new' keyword existed. Urrgh.
Oh I hate it when I let myself get drawn in by flamebait like this.
Given that tools such as Kaffe are no longer needed on Linux now that we have a complete, official JDK from Sun
As someone else has mentioned, there are legitimate concerns about dependance on Java from Sun.
(with a better JIT as well, see the August LJ for info),
Remember - linux does not only run on the x86. What about our PPC cousins? or Alphas?
we know see that they are hawking a bizzare mixture of Linux and Java
Precisely what is so bizzare about Java on linux? Exactly why would it be more sensible to run a program on Java on Solaris? or to run a program on Java on Windows?
If you are hotile to Linux, say so.
If you are hotile to Java, say so.
Do not try to dress either up as a legitimate concern about the particular combination of technologies.
(with XML thrown in for buzzword compliance)
<sarcasm>Yes, it would be so much better if they used a binary format. Then they could change it with each new version of the windowing system, and make the new format incompatible with the old one. This whole 'XML' thing is made up for tree-hugging hippies anyway. People should use Word.docs, rather than HTML files. Pass me my crack pipe.</sarcasm>
People buy PDA's to jot little notes or as an address book.
Wow.
I haven't heard a statement with such vison and foresight since Bill Gates stated that no-one would need more 1MB of memory.
Seriously though, this may well be true at the minute, but it is changing all the time. I guess the wave that is currently hitting is text messaging and mobile email. I don't know what will come next. But I would hope a PDA that I bought tommorow would be flexible enough so I could hardware/software upgrade - rather than bin it for a new one.
Why bog down an already slow processor and waste precious battery lifetime running a bloated JVM when native code would work just as well?
Yes! Except, uh native code doesn't work as well.
Portability is an important issue.
I seem to recall there being a hardware indepentant format for WinCE binaries, to cope with the fact that different CE handhelds are using different processors.
Do you like the fact, that if you find a neat little utility for your palm pilot {eg}, you cannot use it on your PC, and you cannot give it to your friend, who owns a CE machine? Seems a dumb situation to me.
For small systems like PDAs, speed is a much more important factor than portability.
Great claim. Doesn't really stand up to a reality check. And anyway, this seems inconsistant with a previous point of yours. Just how much processor power do you need to 'jot little notes or as an address book'?
The palm is the most popular handheld. It runs on a 16bit by 16mhz processor. Go figure. More power would be nice, for playing mp3s, etc. But that is just 'another feature to list on the box ', isn't it?
All in all, this seems to be YA Linux PDA: loaded with features no one wants, no one needs, and no one will use.
Fine. Calm down, stop bitching about it, and let people make that decision themselves and vote with their wallets.
But hey, it's got a penguin on it, so that's guarenteed sales to the geek demographic.
Ah, sadly true.
Can't argue with this.
Okay, sorry if I get a little flamey at places, but you make too many strong yet unsubstanciated claims and self contradictory statements here.
I guess people keep having to come up with their own licenses all the time, as the GPL isn't GPL'd.:-) Anyways, I doubt that the IBM legal department would be all that happy if people just started releasing code under of the shelf licenses - aside from many concerns they may have about the license, it would make them rather redundant!
At a glance, the licence looks quite GPL-ish to me, ie if you redistribute you must make source available& the license, or an equivalent one, propagates.
IBM may publish new versions (including revisions) of this Agreement from time to time.
I guess one genuine reason that everyone needs their own license, is that everyone needs to state who it is who has the right to change the license at a later date. Remember: FSF retains copyright over the GPL.
You make a good point. But bear in mind that the GPL is designed to prevent this kind of fragmentation. How do you add extensions to the system? Eg. extra syscalls - you modify the source. It is GPL'ed, you have to GPL and release your source. Now any of your competitors have your extensions, and the right to include them in their version of the software. The GPL virus spreads. Yey! It certainly makes life more difficult. I could also argue that the big UNIX vendors may have learnt from their mistakes, and should realize that they make their money from hardware, and more software == more sales. But that is too utopian a vision.
However, if you are right, I would like to suggest that foo may be Symbian.
well the endian-ness would be the biggest problem.
Not necessarily true. I believe that the IA-64 architecture supports switching the endian-ness on the fly (ie can be either). No reason why the Crusoe can't do the same.
The rest would probably be resolvable with a meta- VM-WAREish approach
There would be no need for VM-WAREish software. This is not what the crusoe is all about. There is nothing out of the ordinary about the Crusoe processor (it is a neat, modern, VLIW processor - but nothing wierd). All of Transmeta's patents are to do with the MMU (memory management unit). It has designed to spot when memory addresses do not exist in physical memory - are memory mapped IO any need to be treated differently. The whole point of the Crusoe is that it effectively does VM-WARE's job in hardware.
To quote Transmeta's site: Transmeta's Code Morphing technology is obviously not limited to x86 implementations.
The code-morphing should be pretty simple - cross compiling from one instruction set to another is generally easy - except when you trip over on the memory mapped IO. It should only become really difficult if the code is doing really fun stuff: self-modifying code, overlaid opcodes, trampolining on the stack, etc.
Should make no difference compiling from PPC rather than x86.
The only thing I miss about NeXT is the style of the black hardware
Ring Dell. Say you have their spring 2000 catalogue, and ask about bundle code BLK19. (btw. I don't work for them, just their catalogue is in front of me) $499 for a black mouse (logitech), black keyboard (belkin), and black 19".26mm Viewsonic monitor, res up to 1600x1280. By the look of it, it comes with speakers, too (black).
Now all you need is the case. I've taken a can of spray paint to my computer before now. Cost: $5-$10? [actually, I agree, jet black computer hardware is cool. I've taken a can of black spray paint to a keyboard before now, but that was less NeXT style, more hitchhikers guide to the galaxy.]
On the whole JIT vs static compiling issue, I'd like to point out HP's Dynamo (I own credit for this link to toh, from a recent post on askslashdot). Anyway, what HP are doing, is a VM like Sun's hotspot, initially interpreting code, then JIT compiling it. The interesting thing, is it compiles from HP-PA to HP-PA.:-) The idea is to optomize the most commonly used bits of code, while the program is running.
The JIT gives a 10%-15% speed increase over running the code without the VM.
You make a very valid point, that running Java on Windows can be a pain (or rather, getting it installed in the first place).
But this may improve, due to the DOJ / Microsoft trial. The appeals may delay the split for years, but as I understand it, some of the controls kick in within the the next two months. I think, MS will be stopped from restricting what software (read: Netscape) may be installed on PCs when they are shipped. This may mean companies start selling PCs supporting Java out the box. MacOS X supporting Java2 out the box may help encourage PC manufacturers in the right direction:-)
A "stateless" console system--one with the typical console hardware and no additions like a hard drive or peripherals--makes for a much more standardized gaming experience for the user--if the game you make works on your Dreamcast, it'll work on everyone's Dreamcast, because there's no worry that the user might have a different video card than you, for example.
You seem quite happy with the fact consoles are becoming more like PCs - personally, I think it's a shame - for this very reason.
I'm a die-hard home computer/PC gamer, ever since the Sinclair Spectrum, and have never owned a console (well, except a gameboy, but that doesn't count;-). But I like consoles like the Dreamcast, because everything just works.
With the evolution of OSs, software, and hardware on PC's i feel that eventually pc's will eventually be used primarily for development, mission critical applications, and serving a broad range from home network administration to asp's.
Yeah, PCs as we know them may become rarer, like you say with devices like consoles taking their roles, but I doubt that they will die out. In the same way that there are car enthusiasts, who fix up their own hot-rod, there will be PC enthusiasts, who tinker with their PCs.
Carmack explains, "it's not a matter of a game console versus a PC, it's more a matter of PC versus another gaming platform."
Take a PSX2/Xbox with a harddrive, hook a modem, keyboard & mouse up to the USB ports, and you've got yourself a PC, in my book. It may not be a PC in the "IMB compatible" sense - but you still hear people reffer to Apple's as PCs, as in "Personal Computer". The only difference is that is has a funky custom chipset and you plug it into your TV set - sounds like this could be the new Amiga we have been waiting for.
It's like the difference between night... and slightly later that night;-)
Finally, a little off topic, but if you are reading this article, you may be interested in this link, that I spotted on the page: Mein Leiben!
I've had a glance over the articles you linked - very interesting, and I'll read them properly later.
If you look at what HP is doing with Dynamo [...]
Cool stuff - this is also about the same way that Sun's Hotspot JVM works.
The problem with most JIT compilers is that there is a trade off between the speed the code runs at, and the time the system takes to load. The more heavily optomizing your compiler is, the longer compile times are. With hotspot, bytecode is initially interpreted. The system looks for hotspots in the code, and compiles these into very tight code. Code that rarely runs may always be interpreted, but this doesn't matter.
The key difference between the two presumably comes down to memory - the fact that Dynamo is compiling from HP-PA to HP-PA means that any assumptions that the code makes about the nature of memory only have to *remain* correct. The fact that memory regions may actually be memory mapped IO makes cross compilation from one instruction set to another a lot harder. This is why Crusoe needs such a smart mmu, and one of the reason why Java limits memory access to memory refernces as opposed to pointers. Harder but not impossible - I know of a project to provide fast software emulation of ISA's for old mainframe hardware, which is no longer available, using this kind of cross compilation. (plus of course, stuff like softwindows for the Mac) Like I say, cool stuff.
One thing that you may find interesting - the article on Dynamo ends saying imagine this for x86... well i know someone working on a system for Linux that kindof does this. Unlike Dynamo, it doesn't do it at runtime, though. With Dynamo, you interpret all the code, and as you are doing this you can anaylze what parts of the code are hotspots. The project he is involved in makes use of the performance profiling tools already available in Linux. The idea is as a program runs you compile statistics of where the program is spending most its time. You then regularly optomize your system, ensuring that the most common path is the one with the least jumps (& therefore stalls), but recompiling code on your harddisk, not in memory (compiling x86 to x86). It is a different approch, not optomizing at runtime, but with similar results.
there are simply too many things in a modern superscalar design that can't be known at static compile time
Very good point. I read something a while back pointing out that java (or any other bytecode) programs may run faster than native code on intel Itaniums. The Itanium is an interesting chip. Skip on if you know this, but for those who don't.....
The pentium II/III chips have a number of floating point units. When the processor hits a floating point intstruction it allocates a fpu to the task: if none are available it stalls until one is. [this description may not be perfect - I'm into low-level code, but not hardware:-)] In the Itanium, specialist execution units have to be allocated for every type of instruction, so you have units like floating point units, memory units, maths units, etc. Operations like multiplication require a maths unit, but things like addition can be done by a maths unit, or a memory unit (which is a basic RISC ALU). Different versions of the chip may have differing numbers of the units (eg. an Itanium for a graphics workstation may have more floating point units, one for a server may have more memory units). A static compiler cannot know how many units of each different type the processor it will run on will have - a JIT can.
So I guess that's what my own answer to "what is the future of programming languages" depends on. One thing I'll say is that I'm not sure it's Java,
Why the hell not?! ;-) Seriously, are you talking about the language, or the bytecode instruction set here?
What do you feel java is lacking?
It's an idea in many ways similar to Crusoe or even (shudder) EPIC, but doing things at different times and in different places.
Why the shudder? If there is a draft in here I can shut the door...
Seriously though, why don't you like EPIC?
Can't say that I know much about any other VLIW processors myself.
What I mean is this: Microcode allows you to soft-code each "instruction" in the instruction set. There is therefore nothing to stop you making those as high-level as you like.
That's true. But keep in mind that microcode existed before RISC instruction sets..... I think it was the VAX that had an assembly-level instruction for "find the roots of this polynomial".
To bring this back to the root of the thread, the Crusoe:
RISC was a step away from microcode, in that if you look at how a MIPS processor executed an instruction, the instruction directly sets the datapaths through the processor with, no decode necessary. <opinion>The reason the RISC chips no longer have an edge over CISC chips, is because the RISC instruction sets no longer match up with how a processor executes the code. A pIII is a superscalar core, with a CISC decoder on the front end - a MIPS R12000 is a superscalar core with a RISC decoder on the front end. No difference. In the Crusoe & Itanium, the VLIW instruction set directly matches the way the core works, in the same way that the actualy bit patterns of MIPS instruction set matched the MIPS hardware.</opinion> (okay, the memory/processor speed ratio has an impact on the efficience of RISC, too).
The whole idea you suggest about massively parallel reprogrammable hardware - very cool, very interesting, but I'm not holding my breath to see it in the short-term future. I have actually heard of one system simiral to this in existance, though. It was a machine based on the xylinx (sp?) fpga processors. As I recall, it was the size of a mini-tower PC, and as powerful as your average supercomputer. Cost about half a million bucks, I think.
So far as the stuff about high-level instructions in microcode, the last project that I know to design a processor this high-level, was a stack-based processor from Sun that natively executed java bytecode. I believe this has since been canned, for the same reasons that people moved from processors as CISC as those in the VAX to more RISCy machines. The way that people seem to be designing processors to are RISC/VLIW processors.
I believe that is is possible to flash update the Pentium pro/II/III microcode on the fly, to fix bugs. Presuming that you can modify the microcode involved in instruction-decode, I guess you could make a pentium run a coompletely different instruction set:-) This would be a *very* cool, if impractical, way to write a JVM.
Finally - to get back to the original ask slashdot - my opinion on the future of programming languages, is that in execution they should be architecture neutral, in that they compile to a bytecode. Why? The difference between a RISC/CISC processor and a VLIW processor is the fact that RISC/CISC processors have a decoder on the front end for an outdated instruction set. we should buffer against the changing requirment the hardware has of the instruction set, by a adopting a 3 tier approach to execution - in the same way that databases buffer against change in the way data is stored. That means a intermediate, step, such as bytecode.
Not that size is the only concern (so my wife keeps telling me),
It's not how big your OS kernel is, it's what you do with it that matters;-)
Hurd [is] now obsolete too.
This is really bad news, since it hasn't even hit a 1.0 release yet:-) Why do you say this? not being arguementative - just interested.
I just want to highlight this link from the previous post. I hadn't seen this site before, and I really wish I had found it a year ago when I started getting into OS coding. If you are at all interested in OS coding, check it out.
In linux, at the time and hopefully forever, just one CPU can be in the (micro-)kernel at one time.
Are you sure? - I don't think so.
Access to sensative areas of code are protected by locking the kernel (shockingly, using calls to the functions 'lock_kernel();' and 'unlock_kernel();':-)
As I understand it, there are many areas of the kernel that are not brilliantly written for SMP (can you say IP stacks:-). Kernel locks are held when they are not needed, so in practice what you say may often be true. But this is changing, and is not the nature of the way the kernel works.
Slashdot Mirror
- With Jikes, you have a number of options, including obfuscation (which is just an algorithm to reduce code size -- smaller class & var names are used).
As I understand it, the obfuscation is only for protection of source code. Using the line number & local variable name tables, it is relatively easy to decompile code with a very high level of accuracy.Obfuscation has relatively little impact on program size, and no impact on runtime speed. With the use of the constant pool, there is only one copy of any class name, variable name, etc. I guess the code size could have an impact when you are downloading applets. But then you should be putting stuff in a jar anyway. At runtime the longer names in the code have no impact. Even in the earliest interpreting VM from Sun, the first time a method is called / field is accessed, the code modifies itself to replace the call/access instruction with a fast version. Once you take into account the 90/10 rule....
I could be wrong. :-)
It has been known to happen occasionally
- IDE's like JBuilder may actually have their use, if you just want to quickly make GUI's and concentrate on code internals. It deals with most of the Swing/AWT for you. Available on Linux. Automates some things for bad codewriters you might work with, to cut down on bugs.
I don't use IDEs - so the following is pretty uninformed. But the slowest and most convualuted piece of code that I have ever seen came from a Java IDE. (I think VisualAge was too blame.) It actually used- Class.forName("...").newInstance(...);
to create instances of other classes also produced by the IDE - it was as if the programmers didn't know the 'new' keyword existed. Urrgh.Trolling for Larry Wall are we?
-
Given that tools such as Kaffe are no longer needed on Linux now that we have a complete, official JDK from Sun
As someone else has mentioned, there are legitimate concerns about dependance on Java from Sun.-
(with a better JIT as well, see the August LJ for info),
Remember - linux does not only run on the x86. What about our PPC cousins? or Alphas?-
we know see that they are hawking a bizzare mixture of Linux and Java
Precisely what is so bizzare about Java on linux? Exactly why would it be more sensible to run a program on Java on Solaris? or to run a program on Java on Windows?If you are hotile to Linux, say so.
If you are hotile to Java, say so.
Do not try to dress either up as a legitimate concern about the particular combination of technologies.
-
(with XML thrown in for buzzword compliance)
<sarcasm>Yes, it would be so much better if they used a binary format. Then they could change it with each new version of the windowing system, and make the new format incompatible with the old one. This whole 'XML' thing is made up for tree-hugging hippies anyway. People should use Word-
People buy PDA's to jot little notes or as an address book.
Wow.I haven't heard a statement with such vison and foresight since Bill Gates stated that no-one would need more 1MB of memory.
Seriously though, this may well be true at the minute, but it is changing all the time. I guess the wave that is currently hitting is text messaging and mobile email. I don't know what will come next. But I would hope a PDA that I bought tommorow would be flexible enough so I could hardware/software upgrade - rather than bin it for a new one.
-
Why bog down an already slow processor and waste precious battery lifetime running a bloated JVM when native code would work just as well?
Yes! Except, uh native code doesn't work as well.Portability is an important issue.
I seem to recall there being a hardware indepentant format for WinCE binaries, to cope with the fact that different CE handhelds are using different processors.
Do you like the fact, that if you find a neat little utility for your palm pilot {eg}, you cannot use it on your PC, and you cannot give it to your friend, who owns a CE machine? Seems a dumb situation to me.
-
For small systems like PDAs, speed is a much more important factor than portability.
Great claim. Doesn't really stand up to a reality check. And anyway, this seems inconsistant with a previous point of yours. Just how much processor power do you need to 'jot little notes or as an address book'?The palm is the most popular handheld. It runs on a 16bit by 16mhz processor. Go figure. More power would be nice, for playing mp3s, etc. But that is just 'another feature to list on the box ', isn't it?
-
All in all, this seems to be YA Linux PDA: loaded with features no one wants, no one needs, and no one will use.
Fine. Calm down, stop bitching about it, and let people make that decision themselves and vote with their wallets.-
But hey, it's got a penguin on it, so that's guarenteed sales to the geek demographic.
Ah, sadly true.Can't argue with this.
Okay, sorry if I get a little flamey at places, but you make too many strong yet unsubstanciated claims and self contradictory statements here.
G
I guess Stephen King's experiment has taken off.
Maybe he will only publish the third atricle if a certain number of employees of said "major software company" quit.
:-)
- THE LADY BUG IS HURTING ME!!!
Yeah, but can you imagine a Beowulf swarm of these things?I'm sorry, I'm sorry. I'll punch myself in the face for that one :-)
- Opening up the code for anything (even if MS did it) is a good deal,
Amen halleluja to that, brotherHere is a link to the IBM public license.
I guess people keep having to come up with their own licenses all the time, as the GPL isn't GPL'd. :-) Anyways, I doubt that the IBM legal department would be all that happy if people just started releasing code under of the shelf licenses - aside from many concerns they may have about the license, it would make them rather redundant!
At a glance, the licence looks quite GPL-ish to me, ie if you redistribute you must make source available& the license, or an equivalent one, propagates.
- IBM may publish new versions (including revisions) of this Agreement from time to time.
I guess one genuine reason that everyone needs their own license, is that everyone needs to state who it is who has the right to change the license at a later date. Remember: FSF retains copyright over the GPL.cheers,
G
I know I shouldn't feed you trolls, but what the hell....
Don't play ignorant.
You know that when the guy says GPF, he's talking about BSODs.
Are you suggesting that this piece of code will produce a kernel panic? That would be the nearest equivalent.
You are deliberately missing the point.
I like the idea of writing a C compiler that will only compile code that reads as a haiku:
int a = 3;
if (a < 200)
printf("Sushi Rules!");
Mmmmmm, warm fuzzy feeling inside.
***** Ooops, forgot to preview, sorry!
I like the idea of writing a C compiler that will only compile code that reads as a haiku:
int a = 3;
if (a 200)
printf("Sushi Rules!");
Mmmmmm, warm fuzzy feeling inside.
Worked fine for me.
Where did you register that?
I was under the impression that registrars weren't registering offencive domain names.
cheers,
G
Not a flame - the story was rather short, and void of detail.
Does anyone know what Novell have that is currently of value to IBM?
Eg. you can see why Caldera snapped up SCO.
cheers,
G
- You make a good point. But bear in mind that the GPL is designed to prevent this kind of fragmentation. How do you add extensions to the system? Eg. extra syscalls - you modify the source. It is GPL'ed, you have to GPL and release your source. Now any of your competitors have your extensions, and the right to include them in their version of the software. The GPL virus spreads. Yey! It certainly makes life more difficult. I could also argue that the big UNIX vendors may have learnt from their mistakes, and should realize that they make their money from hardware, and more software == more sales. But that is too utopian a vision.
- However, if you are right, I would like to suggest that foo may be Symbian.
cheers,G
- well the endian-ness would be the biggest problem.
Not necessarily true. I believe that the IA-64 architecture supports switching the endian-ness on the fly (ie can be either). No reason why the Crusoe can't do the same.- The rest would probably be resolvable with a meta- VM-WAREish approach
There would be no need for VM-WAREish software. This is not what the crusoe is all about. There is nothing out of the ordinary about the Crusoe processor (it is a neat, modern, VLIW processor - but nothing wierd). All of Transmeta's patents are to do with the MMU (memory management unit). It has designed to spot when memory addresses do not exist in physical memory - are memory mapped IO any need to be treated differently. The whole point of the Crusoe is that it effectively does VM-WARE's job in hardware.To quote Transmeta's site: Transmeta's Code Morphing technology is obviously not limited to x86 implementations.
The code-morphing should be pretty simple - cross compiling from one instruction set to another is generally easy - except when you trip over on the memory mapped IO. It should only become really difficult if the code is doing really fun stuff: self-modifying code, overlaid opcodes, trampolining on the stack, etc.
Should make no difference compiling from PPC rather than x86.
cheers,
G
- Plus lots more... its worse then trying to read that 31337 crap...
Oh, Does this make it any better?;-)
- Someone stops me on the street, and says "Excuse me, do you know what the time is?"
They are wasting my time.They are wasting my resources.
- Someone scans my ports.
They are wasting my bandwidth.They are wasting my resources.
Should I be able to sue you for asking me what the time is?
Your point is entirely correct, but I think putting up with things that are inconvenient to us is part of living in a liberal democracy.
But global ananlysis is very difficult amid the untamed world of C pointers (aliasing problems)
- What is global ananlysis?
- What are aliasing problems?
- What are C pointers? (no, kidding.)
Seriously, you lost me by the word 'analysis', but I am interested - do you have any links you can suggest / a brief explaination?cheers,
G
Ring Dell. Say you have their spring 2000 catalogue, and ask about bundle code BLK19. (btw. I don't work for them, just their catalogue is in front of me) $499 for a black mouse (logitech), black keyboard (belkin), and black 19" .26mm Viewsonic monitor, res up to 1600x1280. By the look of it, it comes with speakers, too (black).
Now all you need is the case. I've taken a can of spray paint to my computer before now. Cost: $5-$10? [actually, I agree, jet black computer hardware is cool. I've taken a can of black spray paint to a keyboard before now, but that was less NeXT style, more hitchhikers guide to the galaxy.]
:-)
G
The JIT gives a 10%-15% speed increase over running the code without the VM.
You make a very valid point, that running Java on Windows can be a pain (or rather, getting it installed in the first place).
But this may improve, due to the DOJ / Microsoft trial. The appeals may delay the split for years, but as I understand it, some of the controls kick in within the the next two months. I think, MS will be stopped from restricting what software (read: Netscape) may be installed on PCs when they are shipped. This may mean companies start selling PCs supporting Java out the box. MacOS X supporting Java2 out the box may help encourage PC manufacturers in the right direction :-)
I always though Super Mario Brothers owed it's origins to Manic Miner ;-)
ps, NES fans, smile, be happy, and please don't take this as flamebait :-)
You seem quite happy with the fact consoles are becoming more like PCs - personally, I think it's a shame - for this very reason.
I'm a die-hard home computer/PC gamer, ever since the Sinclair Spectrum, and have never owned a console (well, except a gameboy, but that doesn't count ;-). But I like consoles like the Dreamcast, because everything just works.
With the evolution of OSs, software, and hardware on PC's i feel that eventually pc's will eventually be used primarily for development, mission critical applications, and serving a broad range from home network administration to asp's.
Yeah, PCs as we know them may become rarer, like you say with devices like consoles taking their roles, but I doubt that they will die out. In the same way that there are car enthusiasts, who fix up their own hot-rod, there will be PC enthusiasts, who tinker with their PCs.
Carmack explains, "it's not a matter of a game console versus a PC, it's more a matter of PC versus another gaming platform."
Take a PSX2/Xbox with a harddrive, hook a modem, keyboard & mouse up to the USB ports, and you've got yourself a PC, in my book. It may not be a PC in the "IMB compatible" sense - but you still hear people reffer to Apple's as PCs, as in "Personal Computer". The only difference is that is has a funky custom chipset and you plug it into your TV set - sounds like this could be the new Amiga we have been waiting for.
It's like the difference between night ... and slightly later that night ;-)
Finally, a little off topic, but if you are reading this article, you may be interested in this link, that I spotted on the page: Mein Leiben!
Nyet!
Caffeine for mind.
Pizza for body.
Sushi... for SOUL.
If you look at what HP is doing with Dynamo [...]
Cool stuff - this is also about the same way that Sun's Hotspot JVM works. The problem with most JIT compilers is that there is a trade off between the speed the code runs at, and the time the system takes to load. The more heavily optomizing your compiler is, the longer compile times are. With hotspot, bytecode is initially interpreted. The system looks for hotspots in the code, and compiles these into very tight code. Code that rarely runs may always be interpreted, but this doesn't matter.
The key difference between the two presumably comes down to memory - the fact that Dynamo is compiling from HP-PA to HP-PA means that any assumptions that the code makes about the nature of memory only have to *remain* correct. The fact that memory regions may actually be memory mapped IO makes cross compilation from one instruction set to another a lot harder. This is why Crusoe needs such a smart mmu, and one of the reason why Java limits memory access to memory refernces as opposed to pointers. Harder but not impossible - I know of a project to provide fast software emulation of ISA's for old mainframe hardware, which is no longer available, using this kind of cross compilation. (plus of course, stuff like softwindows for the Mac) Like I say, cool stuff.
One thing that you may find interesting - the article on Dynamo ends saying imagine this for x86... well i know someone working on a system for Linux that kindof does this. Unlike Dynamo, it doesn't do it at runtime, though. With Dynamo, you interpret all the code, and as you are doing this you can anaylze what parts of the code are hotspots. The project he is involved in makes use of the performance profiling tools already available in Linux. The idea is as a program runs you compile statistics of where the program is spending most its time. You then regularly optomize your system, ensuring that the most common path is the one with the least jumps (& therefore stalls), but recompiling code on your harddisk, not in memory (compiling x86 to x86). It is a different approch, not optomizing at runtime, but with similar results.
there are simply too many things in a modern superscalar design that can't be known at static compile time
Very good point. I read something a while back pointing out that java (or any other bytecode) programs may run faster than native code on intel Itaniums. The Itanium is an interesting chip. Skip on if you know this, but for those who don't.....
The pentium II/III chips have a number of floating point units. When the processor hits a floating point intstruction it allocates a fpu to the task: if none are available it stalls until one is. [this description may not be perfect - I'm into low-level code, but not hardware :-)] In the Itanium, specialist execution units have to be allocated for every type of instruction, so you have units like floating point units, memory units, maths units, etc. Operations like multiplication require a maths unit, but things like addition can be done by a maths unit, or a memory unit (which is a basic RISC ALU). Different versions of the chip may have differing numbers of the units (eg. an Itanium for a graphics workstation may have more floating point units, one for a server may have more memory units). A static compiler cannot know how many units of each different type the processor it will run on will have - a JIT can.
So I guess that's what my own answer to "what is the future of programming languages" depends on. One thing I'll say is that I'm not sure it's Java,
Why the hell not?!
;-)
Seriously, are you talking about the language, or the bytecode instruction set here?
What do you feel java is lacking?
It's an idea in many ways similar to Crusoe or even (shudder) EPIC, but doing things at different times and in different places.
Why the shudder?
If there is a draft in here I can shut the door... Seriously though, why don't you like EPIC? Can't say that I know much about any other VLIW processors myself.
cheers,
G
- What I mean is this: Microcode allows you to soft-code each "instruction" in the instruction set. There is therefore nothing to stop you making those as high-level as you like.
That's true. But keep in mind that microcode existed before RISC instruction setsTo bring this back to the root of the thread, the Crusoe:
RISC was a step away from microcode, in that if you look at how a MIPS processor executed an instruction, the instruction directly sets the datapaths through the processor with, no decode necessary. <opinion>The reason the RISC chips no longer have an edge over CISC chips, is because the RISC instruction sets no longer match up with how a processor executes the code. A pIII is a superscalar core, with a CISC decoder on the front end - a MIPS R12000 is a superscalar core with a RISC decoder on the front end. No difference. In the Crusoe & Itanium, the VLIW instruction set directly matches the way the core works, in the same way that the actualy bit patterns of MIPS instruction set matched the MIPS hardware.</opinion> (okay, the memory/processor speed ratio has an impact on the efficience of RISC, too).
The whole idea you suggest about massively parallel reprogrammable hardware - very cool, very interesting, but I'm not holding my breath to see it in the short-term future. I have actually heard of one system simiral to this in existance, though. It was a machine based on the xylinx (sp?) fpga processors. As I recall, it was the size of a mini-tower PC, and as powerful as your average supercomputer. Cost about half a million bucks, I think.
So far as the stuff about high-level instructions in microcode, the last project that I know to design a processor this high-level, was a stack-based processor from Sun that natively executed java bytecode. I believe this has since been canned, for the same reasons that people moved from processors as CISC as those in the VAX to more RISCy machines. The way that people seem to be designing processors to are RISC/VLIW processors.
I believe that is is possible to flash update the Pentium pro/II/III microcode on the fly, to fix bugs. Presuming that you can modify the microcode involved in instruction-decode, I guess you could make a pentium run a coompletely different instruction set :-)
This would be a *very* cool, if impractical, way to write a JVM.
Finally - to get back to the original ask slashdot - my opinion on the future of programming languages, is that in execution they should be architecture neutral, in that they compile to a bytecode. Why? The difference between a RISC/CISC processor and a VLIW processor is the fact that RISC/CISC processors have a decoder on the front end for an outdated instruction set. we should buffer against the changing requirment the hardware has of the instruction set, by a adopting a 3 tier approach to execution - in the same way that databases buffer against change in the way data is stored. That means a intermediate, step, such as bytecode.
End rant :-P
It's not how big your OS kernel is, it's what you do with it that matters ;-)
Hurd [is] now obsolete too.
This is really bad news, since it hasn't even hit a 1.0 release yet :-)
Why do you say this? not being arguementative - just interested.
I just want to highlight this link from the previous post. I hadn't seen this site before, and I really wish I had found it a year ago when I started getting into OS coding.
If you are at all interested in OS coding, check it out.
cheers,
G
Are you sure? - I don't think so.
Access to sensative areas of code are protected by locking the kernel (shockingly, using calls to the functions 'lock_kernel();' and 'unlock_kernel();' :-)
As I understand it, there are many areas of the kernel that are not brilliantly written for SMP (can you say IP stacks :-). Kernel locks are held when they are not needed, so in practice what you say may often be true. But this is changing, and is not the nature of the way the kernel works.
cheers
G