Someone check I've got this right but I think the following machines started out as game consoles:
VIC-20 ATARI 8 BIT C64 - Not sure - I don't think so.... AMIGA (FOR SURE)
Lets look at the last one - the Amiga. When it was released the Amiga was pretty amazing. Every geek who was around drooled at it that I knew. For business sales it sucked - as hard as Commodore pushed it. Nobody is going to run *big* serious business computing stuff on a PS3 - OK Some might, but Sony is not battling the same war. Everyone knows what a PC is, they know what a Mac is.
The key point in the argument between 'Videogames as computers sucked' is that the world is a different place today versus back then. The set top box / computer functionality has moved into the living room as an integral part of the entertainment experience.
Sony isn't entirely insane. They want to *OWN* the living room. PC sales dont matter in the big picture to Sony, they would much rather have a future Amiga type system with cool custom hardware and lots of wonderful DRM.
If Sony really wants to win they should do the following:
1) Put in hardware deadlocks that allow the machine to safely do DRM. (This is very hard when we get to #2)
2) Open up as much of the hardware and software as possible. Publish the hardware specs. Publish the software specs. Let anyone who has the desire hack on the system.
3) Make sure that the machine can be reset back to 'Safe DRM mode' so when the folks get home they can still use it even if Junior has written a new function level programming language.
What disadvantages does this have:
1) The same one as the Amiga. It was a fixed target, it didn't evolve like the PC for games. The flipside is that it is a fixed target and people get to know it really well. How long does the PS3 have to last? 5 Years? Then they just make the entire PS3 a single chip on the PS4.
2) Your gonna get your hardware cracked at some point. Someone will figure out how to crack it. The question is how many people actually do this. How much money has Sony actually lost from Mod chips on the PS2? Probably not that much I would guess.
3) You have to battle off the PC coming down into the living room. You have to battle off MS with a new enhanced XBOX-360 that is similar.
Sonys really advantage is they don't own the PC platform. They aren't tied to Windows. If they were smart they would use this, they would stick Linux on the PS3, they would let people write code on it, and see what happens. They would let the PS3 evolve into its own thing. Nobody knew that people were gonna use Apple II's for VISICALC...
It could be a disaster - but it already seems to be sounding more and more like a disaster, so they may as well at least try and cause the biggest upheavel to the computer industry they can. They arent going to win with the status quo.
I wonder if it is feasible to fire a solid block of ice (projectile shaped) into orbit. I wonder how much would ablate due to frictional heating. If you use a large enough electrical arc at the base you could use some of the ice of the projectile as the reaction mass.
The density is obviously lower than liquid water - but theres no throw away / reuse of the casing required.
Making the projectiles would require freezing water into the projectile form. It may be cost effective to make a larger solid ice projectile and accept the ablative loss.
If you really want to get serious about space exploration you have to consider the energy density of what your sending. The best use of the ice / water on orbit may be as reaction mass for a nuclear thermal rocket.
Is anybody else frustrated by the insane degree of compression / other BS going on when they watch PPV movies on cable? The video gets choppy during fast action sequences, looks horrible when there's smoke or fire, and generally the user experience sucks.
It really frustrates the hell out of me that we are now all talking about 'HD' this and 'HD' that and you can't even get the equivalent of Studio Grade PAL or NTSC when watching PPV on a typical consumer cable connection.
In a perfect world I'd like to see companies start offering guaranteed bitrate movies. The bitrate / userexperience is equivalent to watching a DVD.
I know that is unlikely to happen anytime soon - the cable companies want to squeeze as much content into the finite bandwidth of the pipe...
Does anybody have any kind of cable service where they give you a guaranteed bitrate? Yes I know that new codecs can do better with less bitrate but do you really want the cable execs deciding just how crappy a user experience they can get away with?
I only see this getting worse once they start offering HD services. I see cable companies doing something goofy like:
Take original HD master. Reencode at lousy bitrate. Pump down pipe to consumer. Advertise as SUPER GREAT LOOKING HD! PROFIT!
Does the FCC regulate any of this stuff? (I don't know I want them doing that but it's worth asking).
The problem with this argument is that your trying to artifically say what a product should be. If a company chooses to expend effort (cost/time/etc) then that's their choice.
I mean if you take the 'anti' bundling argument to the logical nth degree you could hear someone say:
1) No OS should come with threads - processes are enough, and bundling in 'threads' is an attempt to stop good hard working folks from selling their thread implementation.
2) TCP/IP stack? What! With the OS? That's anti competitive! Your stopping all those other good hard-working folks from selling their own protocol stack! Your putting them out of business! You big nasty evil corporation!
I don't want governments deciding what someone can put in a product. That's a slippery pathway to doom.
If you applied the bundling argument to car manfuacturers: What! Your including a stereo with the car? That's anti-competitive and your putting all those good hard working folks who make and install...
Ultimately the market will decide - that's a market economy. If a company invests too much effort putting what I as a consumer consider useless/unimportant features into a product and thus have to charge more for it to cover the costs associated I can go use/buy the product which is just the lean metal.
Now if a company is purposely making other software not work with theirs, and lying about why then that's a bit rough for the small company, but ultimately they may pay the price of not selling more units of their product which used to work...
Its the 'Walled Garden' approach - and the market has shown that getting it right is tough.
To get it right you need to either:
1) Offer unique content / services / paradigm which has more value than other freely (or cheaper) content from another source
2) Make a big wall - so the consumer has no choice.
Doing 1) Is tough - case in point - AOL. Doing 2) Consumers will run away to the more 'free' choice.
There are counter examples - I mean this is on Slashdot - so clearly Slashdot holds some value which results in the usage of it.
The 'do it all' and extend with proprietary extensions concept is common. You still have to do 1) - if you add proprietary goo that doesn't do something useful nobody will use it / people will use the more open standard.
Even if your standard is better you may lose the war too if theres something else out there that is 'good enough' and cheaper...
I'd love to read some general purpose GPU type benchmarks for these cards. I'm really curious how they perform compared to say the original Nvidia 6800 card. It might be fun to graph the performance and see what the curve looks like compared to CPU performance graphs.
A few years ago I tried writing some code in a modified version of ATARI BASIC known as Turbo BASIC XL. Turbo BASIC is much nicer than regular ATARI BASIC, it allows rudimentary named subroutines and multiline IF's and runs a fair amount quicker than regular Atari BASIC.
I've been programming in *real* languages now since about 89 and here's my experiences with it.
1) The Linenumbers were a *horrible* mental stumbling block. I ended up saving the file in ATASCII and loading it in VI so I could arbitrarily move about. The loss of mental clarity is rough when typing LIST 1000,1200 - oh missed end of that subroutine, try again LIST 1000,1250, OH DAMN top scrolled off screen. (The atari equivalents of CTRL-S and CTRL-Q become your friends). Finally now I see it - Now what was that bug I was looking for Hmmmmm...?
2) Perhaps the *worst* problem with it is the fact that it supports undeclared variables. One typo and your not going to get the response you expected. E.g.
1000 ATTACK=DIFFLEVEL * TIMEELAPSED 1010 IF ATTACK 1 THEN 1020 'Continue updating universe state 1030 ATTACKTYPE = INT ( RND ( 1 ) * 5 ) 1040 NUMATTACK = INT ( RND ( 1 ) * 10 * SKILL )+QUADRANTCHAOS 1050 GLOBALSTATE=CSTATATTACK 1060 ELSE 1070... 1080 ENDIF 1090 EXEC UPDATEMODEL
So let's pretend we actually can have NICE LONG DESCRIPTIVE variable names... Anyway, so you screw up one variable name, say you type QUARANTCHAOS, and suddently you've got a nasty bug. This is *really* painful and hard to find!
3) You don't have anything other than global variables. So you end up trying to fudge parameters like:
Your almost always gonna screw something up. Or you decide that it makes NO SENSE to copy variables into PARAM. So you just make sure before you call the proc that you set the right variables it uses. Your gonna screw up one and your outta luck.
This is with a pretty NICE BASIC from the 80's that gives you named subroutines, multiline IF THEN ELSE.
It's really *tough*. You end up writing all your code in another language and passing it thru a preprocessor you hacked together in say PERL to produce the actual stuff that's interpreted. But that just shows that as a real programmer - you realize that programming in a language like BASIC from the 70's / 80's is incredibly time consuming and painful.
Throwing newbies into this kind of world is just plain cruel.
I *would* make the argument that many un-sullied minds may very well make better PROLOG programmers than those of us with tons of Imperative scar tissue.
Geeze seems like these things need to be programmed in some declarative or functional language vs C then. Programming them in C with multiple threads and getting the timing right must be a god-awful mess.
I do wonder - optimizing and understanding the timing must be much easier (deterministic) because they aren't out-of-order so when you screw up you readily see the results and it isn't masked by your OOO logic.
Thank god as far as consoles it isn't a monoculture. - It will be great to see how it all turns out.
For a console it seems like you wouldn't want to ship intermediate code - I was thinking more for desktops where the idea of binary compatibility is touted. Although I do wonder after these last two comments if the code is such a relatively small size, perhaps you could ship IC and Binaries (for exact target platform) on the same Disc.
That way if you release XBox-720 or Playstation 4 - you could perhaps use the Intermediate Code instead of the raw binaries for PS3... Kinda like a FAT binary - but I would have two separate copies.
I see what your getting at - and taking your point further - Isn't it better to have more instruction cache (which is regular and higher density perhaps) and fill it with lots of simpler more RISCY instructions that can do what the CISCY instructions do anyway.
If you want to take an extreme case - consider a CPU with an 'escape code' which allowed you to essentially place it in a mode where all the internal functional unit busses were accessible from horizontal microcode.
The user/compiler could then craft sequences that performed the exact operations they needed without being constrained by the ISA that was exposed by the CPU designers. In this case the bandwidth required for each instruction may grow - I have no idea how many bits you would need to control the functional units of a current CPU. If that was the case then perhaps you could have a huffman encoded table in the processor that allowed the user crafted huffman encoded external instructions to be executed.
As an example - perhaps my algorithm really wants to do three shifts left and an add by 5, or an AND with 0x07 followed by an ADD of another register.
The idea being that the CPU is a commodity - and perhaps whilst the ISA designed seems nice for one purpose it's suboptimal for other users.
Just an idea.
Other ideas - Load the ISA of your favorite CPU.
I don't expect this to be faster - actually I'd guess it may be considerably slower loading the ISA and having the configurability but it would be interesting to expose all of the hardware to the problem vs constrain the solution to using the ISA that's popular at the moment.
Yup - Code density definitely matters lots in embedded systems - but code density is much less important in the non-embedded space. Fixed instruction size still seems incredibly important - but I often wonder why more thumb like cpu's aren't out there. It seems like the following would be a winning solution:
1) Maximize code density (as long as you can decode quickly). Store dense instructions in cache - and get more instructions in there. 2) Allow complex instructions that run extremely quickly exploiting parallel functional units. Avoid any that make dependency analysis too horrible. 3) Crank the core clock up - devote more chip bandwidth to data fetch vs instruction fetch.
I also liked the MTA Tera idea - I still think that was really interesting. It looks like Sun is kinda going there.
The whole MIPS - pipeline interlocks thing was a bit sad - but I do think MIPS/SGI nailed the R10000 tho:-)
VLIW architectures often got poo-poo'd for the lack of backwards binary compatibility thing - seems like a bit of a moot point now - just ship stuff as intermediate code that gets translated into a binary.
It's not really CISC - complex instructions that kill you - it's the heaps of addressing modes with lots of indirection. That just kills you if you combine that with virtual memory. If you imagine a hypothetical CISC that has an instruction that does 20x as much work as a RISC CPU - but only works on registers then it doesn't seem so bad.
With memory latency being as bad as it is I'm often surprised that more chips don't do CISCY type instruction sequences - you could certainly decrease instruction bandwidth...
A key problem with CISC was that doing virtual memory and handling page faults on a CISC processor was so incredibly insanely complicated that you ended up going insane and designing your pipeline could throw multiple page faults on one instruction and you had a god-awful mess to clean up.
The problem with the Cell is actually pretty interesting. They decided to go for in-order CPU's for the SPE's which means that to get good performance you sure as hell better know what your dependencies are and take into account memory latency etc.
OTOH modern RISC CPU's normally do nice out-of-order stuff which whilst making the CPU more complicated makes life easier for the programmer - compiler.
Itanium took the clean approach - and it flies on FP workloads that the compiler can do a good job on. The PS3 (like Itanium) should rock - once programmers get lots of nice little kernels that do groovy stuff (think super shader programs) in the SPE's. Just that will make the eye candy pretty.
The counter argument is the 'Look at what happened with the i860'. It had amazing performance on kernels but was just totaly evil to program and compiler writers pulled out their hair.
I don't know enough about modern game programming to know if the PS3 route is a good one to take - and it's easy to bitch at Sony for going too far - OTOH look at the PS2 games now vs at release. The PS3 games should slowly get better and better and better if they don't crash and burn and give up...
What does that do to demand? Does anybody have any numbers of this probability? I saw Sir Richard Branson guessing 7% chance each year that the pandemic will occur - he was talking with regards to airline load.
Even if it isn't 33% world oil consumption will drop significantly as airline flights are cancelled - people stop driving to public events for pleasure and business travel gets curtailed.
I remember reading reviews of the M68 - it was supposibly a really good machine - and I also recall that with the BASIC compiler it completed the standard BASIC benchmarks *really* quickly. I always wondered how many were sold.
I bet that was the Garbage collector bug. Concatenate too many strings and hey presto - locked up... A real PITA that one. I have some Peek 65's with src to fix it.
OK
If you answered 'A' to memory size you got back something like
Written by Richard Weiland...
Can't remember exactly but it rocked, and if you wanted to get back your program after it had crashed, you answered 770 to memory size after a cold start, then did a POKE 770,1 - and hey presto your source code was back there and you could save it to tape.
The first OSI machine we got was a Challenger 1P - looked like it was factory assembled. I've also got a C4P MF(Factory built), 3 Superboard II's, a C8P backplane and keyboard with 505 / 502? board and a 540 keyboard/video board...
They were really popular with Hams back in NZ because in the Metal Case they were really quiet in RFI terms. Also I suspect the hacker-add bits nature helped too.
First machine that was 'mine' was an Ohio Scientific Challenger 1P. A Superboard II in a metal case back in about 1982. I still have it and recently fired it up to write the nieces a 'dodge the rocks' game. Nothing like a nice simple memory mapped display and those character graphics.
The C1P had 8K of RAM in 16 2114 chips and 1K of Video RAM ( 2 more 2114's). Along the way we expanded it by:
Populated the RS-232 - A Leir Siegler ADM-1 terminal (80x24 UPPERCASE) - it rocked. A decwriter LA-120 as a printing terminal, an OSI 610 board - 24 more K (48 2114's) and we built up a data seperator and hooked up two Panasonic 5 1/4 floppy drives - OS 65DV3.3
It rocked. I still remember typing in listings from all over the place, and my favorite memory is when I managed to actually get a spaceship to move about under keyboard control...
I spent hours staring at the src code - I could make the ship fly all the way left or all the way right (Two for loops), and then suddenly a light went off in my head and I realized... Hey if I change the for loop for A=A+1 for right shift, and A=A-1 for left shift...
From there on it was a Hitachi Peach MB-6890 - Nice 6809 based machine, Atari 800XL (Graphics! - Display Lists, ANTIC, POKEY, GTIA) - It rocked, then I switched the dark-side and went for a 286.
I ported black hole plotting programs I wrote in TurboBASIC XL from the atari800XL to the 286 in Turbo Pascal - and was astonished as the program that used to take about an hour to display an 80x192 blackhole displayed in about 60 seconds in 800x600x256 colors.
Oh the memories!
The solution IMHO is obvious. Time for the HURD. Implement a clean design for the HURD kernel under the GPL v3. Those who support that standard will walk with their feet. Those who don't will stay with Linux.
The new HURD can be named GNU/HURD or whatever else people want to name it, and it can include whatever licence provisions are desired.
My *guess* is this won't happen - because the RMS crowd realize that fundamentally Linus has produced a better kernel than they could with their resources - and done an excellent job creating an environment for their free software to run on. Linus also realizes he has used their (the free software) tools to produce it.
I agree 100% - the point was - Do you really think that your average consumer who buys the new uC controlled refrigerator with nifty 'email you when out of milk' is going to have any clue about any of that stuff?
Nope, they are going to plug it right in to the 'super-duper highspeed broadband network' and *if* your *lucky* they are going to maybe have a consumer firewall that hasn't been shipped in a totally lame default configuration.
If they change the default password on their firewall and even change the internal subnet address then your *LUCKY*
I'm not talking about the few people who will plug it into their Penguin box with iptables firewall, who has a non darth-vader-unix snort box logging every packet.
I actually wonder what the legal implications of a network attached *anything that could make people sick* is going to be... Just imagine if some nasty script-kiddie SYN floods your refrigerator, and manages to convince it to turn off for say a day or two - at which point some internal watchdog process detects the problem and reboots, and starts cooling again without warning you.
You come home half asleep from a trip eat some food and wind up with food poisoning.
Most users use a firewall to do NAT at the moment., they thus get some level of protection.
Take that away, have loads of IPV6 addresses and un-informed consumers, and your setting yourself up for your uC driven toaster, oven, refrigerator, entertainment center etc spamming people.
It just gives me the screaming heebie-jeebies -- does anyone else remember the feeling of walking into a PeeCee site that was 'internet connected'back in the 90's and asking what they were doing and finding out every un-patched PC had a distinct IP on the internet?
Does anybody know how well Itanium does emulating a RISC ISA like PPC versus CISC ISA like x86? Maybe an Itanium could virtualize a PPC and go at a pretty good clip.
I'm wondering if there is anyone who did an emulator for Alpha VMS binaries for Itanium VMS reading this -- or anyone else who might have an idea.
I looked for SPECFP / SPECINT numbers for 2.7 GHz G5's on spec.org -- but couldn't see them. Does anyone have the numbers so we can validate the '2.7Ghz G5 kicks-butt as is posts?'
Slashdot Mirror
Someone check I've got this right but I think the following machines started out as game consoles:
VIC-20
ATARI 8 BIT
C64 - Not sure - I don't think so....
AMIGA (FOR SURE)
Lets look at the last one - the Amiga. When it was released the Amiga was pretty amazing. Every geek who was around drooled at it that I knew. For business sales it sucked - as hard as Commodore pushed it. Nobody is going to run *big* serious business computing stuff on a PS3 - OK Some might, but Sony is not battling the same war. Everyone knows what a PC is, they know what a Mac is.
The key point in the argument between 'Videogames as computers sucked' is that the world is a different place today versus back then. The set top box / computer functionality has moved into the living room as an integral part of the entertainment experience.
Sony isn't entirely insane. They want to *OWN* the living room. PC sales dont matter in the big picture to Sony, they would much rather have a future Amiga type system with cool custom hardware and lots of wonderful DRM.
If Sony really wants to win they should do the following:
1) Put in hardware deadlocks that allow the machine to safely do DRM. (This is very hard when we get to #2)
2) Open up as much of the hardware and software as possible. Publish the hardware specs. Publish the software specs. Let anyone who has the desire hack on the system.
3) Make sure that the machine can be reset back to 'Safe DRM mode' so when the folks get home they can still use it even if Junior has written a new function level programming language.
What disadvantages does this have:
1) The same one as the Amiga. It was a fixed target, it didn't evolve like the PC for games. The flipside is that it is a fixed target and people get to know it really well. How long does the PS3 have to last? 5 Years? Then they just make the entire PS3 a single chip on the PS4.
2) Your gonna get your hardware cracked at some point. Someone will figure out how to crack it. The question is how many people actually do this. How much money has Sony actually lost from Mod chips on the PS2? Probably not that much I would guess.
3) You have to battle off the PC coming down into the living room. You have to battle off MS with a new enhanced XBOX-360 that is similar.
Sonys really advantage is they don't own the PC platform. They aren't tied to Windows. If they were smart they would use this, they would stick Linux on the PS3, they would let people write code on it, and see what happens. They would let the PS3 evolve into its own thing. Nobody knew that people were gonna use Apple II's for VISICALC...
It could be a disaster - but it already seems to be sounding more and more like a disaster, so they may as well at least try and cause the biggest upheavel to the computer industry they can. They arent going to win with the status quo.
--Tarp
I wonder if it is feasible to fire a solid block of ice (projectile shaped) into orbit. I wonder how much would ablate due to frictional heating. If you use a large enough electrical arc at the base you could use some of the ice of the projectile as the reaction mass.
The density is obviously lower than liquid water - but theres no throw away / reuse of the casing required.
Making the projectiles would require freezing water into the projectile form. It may be cost effective to make a larger solid ice projectile and accept the ablative loss.
If you really want to get serious about space exploration you have to consider the energy density of what your sending. The best use of the ice / water on orbit may be as reaction mass for a nuclear thermal rocket.
--Tarp
Is anybody else frustrated by the insane degree of compression / other BS going on when they watch PPV movies on cable? The video gets choppy during fast action sequences, looks horrible when there's smoke or fire, and generally the user experience sucks.
It really frustrates the hell out of me that we are now all talking about 'HD' this and 'HD' that and you can't even get the equivalent of Studio Grade PAL or NTSC when watching PPV on a typical consumer cable connection.
In a perfect world I'd like to see companies start offering guaranteed bitrate movies. The bitrate / userexperience is equivalent to watching a DVD.
I know that is unlikely to happen anytime soon - the cable companies want to squeeze as much content into the finite bandwidth of the pipe...
Does anybody have any kind of cable service where they give you a guaranteed bitrate? Yes I know that new codecs can do better with less bitrate but do you really want the cable execs deciding just how crappy a user experience they can get away with?
I only see this getting worse once they start offering HD services. I see cable companies doing something goofy like:
Take original HD master. Reencode at lousy bitrate. Pump down pipe to consumer. Advertise as SUPER GREAT LOOKING HD! PROFIT!
Does the FCC regulate any of this stuff? (I don't know I want them doing that but it's worth asking).
The problem with this argument is that your trying to artifically say what a product should be. If a company chooses to expend effort (cost/time/etc) then that's their choice.
...
I mean if you take the 'anti' bundling argument to the logical nth degree you could hear someone say:
1) No OS should come with threads - processes are enough, and bundling in 'threads' is an attempt to stop good hard working folks from selling their thread implementation.
2) TCP/IP stack? What! With the OS? That's anti competitive! Your stopping all those other good hard-working folks from selling their own protocol stack! Your putting them out of business! You big nasty evil corporation!
I don't want governments deciding what someone can put in a product. That's a slippery pathway to doom.
If you applied the bundling argument to car manfuacturers: What! Your including a stereo with the car? That's anti-competitive and your putting all those good hard working folks who make and install
Ultimately the market will decide - that's a market economy. If a company invests too much effort putting what I as a consumer consider useless/unimportant features into a product and thus have to charge more for it to cover the costs associated I can go use/buy the product which is just the lean metal.
Now if a company is purposely making other software not work with theirs, and lying about why then that's a bit rough for the small company, but ultimately they may pay the price of not selling more units of their product which used to work...
It's a tough tradeoff.
Its the 'Walled Garden' approach - and the market has shown that getting it right is tough.
To get it right you need to either:
1) Offer unique content / services / paradigm which has more value than other freely (or cheaper) content from another source
2) Make a big wall - so the consumer has no choice.
Doing 1) Is tough - case in point - AOL.
Doing 2) Consumers will run away to the more 'free' choice.
There are counter examples - I mean this is on Slashdot - so clearly Slashdot holds some value which results in the usage of it.
The 'do it all' and extend with proprietary extensions concept is common. You still have to do 1) - if you add proprietary goo that doesn't do something useful nobody will use it / people will use the more open standard.
Even if your standard is better you may lose the war too if theres something else out there that is 'good enough' and cheaper...
Is anyone coding in any interesting languages like say Mercury, Or Prolog or Lisp on consoles now?
Are any big-title games on PC's being coded in any of the above?
I'd love to read some general purpose GPU type benchmarks for these cards. I'm really curious how they perform compared to say the original Nvidia 6800 card. It might be fun to graph the performance and see what the curve looks like compared to CPU performance graphs.
A few years ago I tried writing some code in a modified version of ATARI BASIC known as Turbo BASIC XL. Turbo BASIC is much nicer than regular ATARI BASIC, it allows rudimentary named subroutines and multiline IF's and runs a fair amount quicker than regular Atari BASIC.
I've been programming in *real* languages now since about 89 and here's my experiences with it.
1) The Linenumbers were a *horrible* mental stumbling block. I ended up saving the file in ATASCII and loading it in VI so I could arbitrarily move about. The loss of mental clarity is rough when typing LIST 1000,1200 - oh missed end of that subroutine, try again LIST 1000,1250, OH DAMN top scrolled off screen. (The atari equivalents of CTRL-S and CTRL-Q become your friends). Finally now I see it - Now what was that bug I was looking for Hmmmmm...?
2) Perhaps the *worst* problem with it is the fact that it supports undeclared variables. One typo and your not going to get the response you expected. E.g.
1000 ATTACK=DIFFLEVEL * TIMEELAPSED
1010 IF ATTACK 1 THEN
1020 'Continue updating universe state
1030 ATTACKTYPE = INT ( RND ( 1 ) * 5 )
1040 NUMATTACK = INT ( RND ( 1 ) * 10 * SKILL )+QUADRANTCHAOS
1050 GLOBALSTATE=CSTATATTACK
1060 ELSE
1070...
1080 ENDIF
1090 EXEC UPDATEMODEL
So let's pretend we actually can have NICE LONG DESCRIPTIVE variable names... Anyway, so you screw up one variable name, say you type QUARANTCHAOS, and suddently you've got a nasty bug. This is *really* painful and hard to find!
3) You don't have anything other than global variables. So you end up trying to fudge parameters like:
PROC ALIENATTACK
ATTACKTYPE=PARAM1
ATTACKLOCA=PARAM2
ENDPROC
Your almost always gonna screw something up. Or you decide that it makes NO SENSE to copy variables into PARAM. So you just make sure before you call the proc that you set the right variables it uses. Your gonna screw up one and your outta luck.
This is with a pretty NICE BASIC from the 80's that gives you named subroutines, multiline IF THEN ELSE.
It's really *tough*. You end up writing all your code in another language and passing it thru a preprocessor you hacked together in say PERL to produce the actual stuff that's interpreted. But that just shows that as a real programmer - you realize that programming in a language like BASIC from the 70's / 80's is incredibly time consuming and painful.
Throwing newbies into this kind of world is just plain cruel.
I *would* make the argument that many un-sullied minds may very well make better PROLOG programmers than those of us with tons of Imperative scar tissue.
--Tarp
I still wish I owned an Archimedes ;-)
Geeze seems like these things need to be programmed in some declarative or functional language vs C then. Programming them in C with multiple threads and getting the timing right must be a god-awful mess.
I do wonder - optimizing and understanding the timing must be much easier (deterministic) because they aren't out-of-order so when you screw up you readily see the results and it isn't masked by your OOO logic.
Thank god as far as consoles it isn't a monoculture. - It will be great to see how it all turns out.
--Tarp
For a console it seems like you wouldn't want to ship intermediate code - I was thinking more for desktops where the idea of binary compatibility is touted. Although I do wonder after these last two comments if the code is such a relatively small size, perhaps you could ship IC and Binaries (for exact target platform) on the same Disc.
That way if you release XBox-720 or Playstation 4 - you could perhaps use the Intermediate Code instead of the raw binaries for PS3... Kinda like a FAT binary - but I would have two separate copies.
Just a crazy idea.
--Tarp
I see what your getting at - and taking your point further - Isn't it better to have more instruction cache (which is regular and higher density perhaps) and fill it with lots of simpler more RISCY instructions that can do what the CISCY instructions do anyway.
If you want to take an extreme case - consider a CPU with an 'escape code' which allowed you to essentially place it in a mode where all the internal functional unit busses were accessible from horizontal microcode.
The user/compiler could then craft sequences that performed the exact operations they needed without being constrained by the ISA that was exposed by the CPU designers. In this case the bandwidth required for each instruction may grow - I have no idea how many bits you would need to control the functional units of a current CPU. If that was the case then perhaps you could have a huffman encoded table in the processor that allowed the user crafted huffman encoded external instructions to be executed.
As an example - perhaps my algorithm really wants to do three shifts left and an add by 5, or an AND with 0x07 followed by an ADD of another register.
The idea being that the CPU is a commodity - and perhaps whilst the ISA designed seems nice for one purpose it's suboptimal for other users.
Just an idea.
Other ideas - Load the ISA of your favorite CPU.
I don't expect this to be faster - actually I'd guess it may be considerably slower loading the ISA and having the configurability but it would be interesting to expose all of the hardware to the problem vs constrain the solution to using the ISA that's popular at the moment.
--Tarp
Yup - Code density definitely matters lots in embedded systems - but code density is much less important in the non-embedded space. Fixed instruction size still seems incredibly important - but I often wonder why more thumb like cpu's aren't out there. It seems like the following would be a winning solution:
:-)
1) Maximize code density (as long as you can decode quickly). Store dense instructions in cache - and get more instructions in there.
2) Allow complex instructions that run extremely quickly exploiting parallel functional units. Avoid any that make dependency analysis too horrible.
3) Crank the core clock up - devote more chip bandwidth to data fetch vs instruction fetch.
I also liked the MTA Tera idea - I still think that was really interesting. It looks like Sun is kinda going there.
The whole MIPS - pipeline interlocks thing was a bit sad - but I do think MIPS/SGI nailed the R10000 tho
VLIW architectures often got poo-poo'd for the lack of backwards binary compatibility thing - seems like a bit of a moot point now - just ship stuff as intermediate code that gets translated into a binary.
--Tarp
It's not really CISC - complex instructions that kill you - it's the heaps of addressing modes with lots of indirection. That just kills you if you combine that with virtual memory. If you imagine a hypothetical CISC that has an instruction that does 20x as much work as a RISC CPU - but only works on registers then it doesn't seem so bad.
With memory latency being as bad as it is I'm often surprised that more chips don't do CISCY type instruction sequences - you could certainly decrease instruction bandwidth...
--Tarp
A key problem with CISC was that doing virtual memory and handling page faults on a CISC processor was so incredibly insanely complicated that you ended up going insane and designing your pipeline could throw multiple page faults on one instruction and you had a god-awful mess to clean up.
The problem with the Cell is actually pretty interesting. They decided to go for in-order CPU's for the SPE's which means that to get good performance you sure as hell better know what your dependencies are and take into account memory latency etc.
OTOH modern RISC CPU's normally do nice out-of-order stuff which whilst making the CPU more complicated makes life easier for the programmer - compiler.
Itanium took the clean approach - and it flies on FP workloads that the compiler can do a good job on. The PS3 (like Itanium) should rock - once programmers get lots of nice little kernels that do groovy stuff (think super shader programs) in the SPE's. Just that will make the eye candy pretty.
The counter argument is the 'Look at what happened with the i860'. It had amazing performance on kernels but was just totaly evil to program and compiler writers pulled out their hair.
I don't know enough about modern game programming to know if the PS3 route is a good one to take - and it's easy to bitch at Sony for going too far - OTOH look at the PS2 games now vs at release. The PS3 games should slowly get better and better and better if they don't crash and burn and give up...
--Tarp
Even if it isn't 33% world oil consumption will drop significantly as airline flights are cancelled - people stop driving to public events for pleasure and business travel gets curtailed.
Anyone have any figures on this?
I remember reading reviews of the M68 - it was supposibly a really good machine - and I also recall that with the BASIC compiler it completed the standard BASIC benchmarks *really* quickly. I always wondered how many were sold.
I bet that was the Garbage collector bug. Concatenate too many strings and hey presto - locked up... A real PITA that one. I have some Peek 65's with src to fix it.
D/C/W/M?
MEMORY SIZE?
TERMINAL WIDTH?
MICROSOFT BASIC V1.0R3.2
(c)1977 MICROSOFT.
OK
If you answered 'A' to memory size you got back something like Written by Richard Weiland...
Can't remember exactly but it rocked, and if you wanted to get back your program after it had crashed, you answered 770 to memory size after a cold start, then did a POKE 770,1 - and hey presto your source code was back there and you could save it to tape.
They were really popular with Hams back in NZ because in the Metal Case they were really quiet in RFI terms. Also I suspect the hacker-add bits nature helped too.
First machine that was 'mine' was an Ohio Scientific Challenger 1P. A Superboard II in a metal case back in about 1982. I still have it and recently fired it up to write the nieces a 'dodge the rocks' game. Nothing like a nice simple memory mapped display and those character graphics. The C1P had 8K of RAM in 16 2114 chips and 1K of Video RAM ( 2 more 2114's). Along the way we expanded it by: Populated the RS-232 - A Leir Siegler ADM-1 terminal (80x24 UPPERCASE) - it rocked. A decwriter LA-120 as a printing terminal, an OSI 610 board - 24 more K (48 2114's) and we built up a data seperator and hooked up two Panasonic 5 1/4 floppy drives - OS 65DV3.3 It rocked. I still remember typing in listings from all over the place, and my favorite memory is when I managed to actually get a spaceship to move about under keyboard control... I spent hours staring at the src code - I could make the ship fly all the way left or all the way right (Two for loops), and then suddenly a light went off in my head and I realized... Hey if I change the for loop for A=A+1 for right shift, and A=A-1 for left shift... From there on it was a Hitachi Peach MB-6890 - Nice 6809 based machine, Atari 800XL (Graphics! - Display Lists, ANTIC, POKEY, GTIA) - It rocked, then I switched the dark-side and went for a 286. I ported black hole plotting programs I wrote in TurboBASIC XL from the atari800XL to the 286 in Turbo Pascal - and was astonished as the program that used to take about an hour to display an 80x192 blackhole displayed in about 60 seconds in 800x600x256 colors. Oh the memories!
My *guess* is this won't happen - because the RMS crowd realize that fundamentally Linus has produced a better kernel than they could with their resources - and done an excellent job creating an environment for their free software to run on. Linus also realizes he has used their (the free software) tools to produce it.
Time for the HURD - Long live Linux.
I agree 100% - the point was - Do you really think that your average consumer who buys the new uC controlled refrigerator with nifty 'email you when out of milk' is going to have any clue about any of that stuff?
Nope, they are going to plug it right in to the 'super-duper highspeed broadband network' and *if* your *lucky* they are going to maybe have a consumer firewall that hasn't been shipped in a totally lame default configuration.
If they change the default password on their firewall and even change the internal subnet address then your *LUCKY*
I'm not talking about the few people who will plug it into their Penguin box with iptables firewall, who has a non darth-vader-unix snort box logging every packet.
I actually wonder what the legal implications of a network attached *anything that could make people sick* is going to be... Just imagine if some nasty script-kiddie SYN floods your refrigerator, and manages to convince it to turn off for say a day or two - at which point some internal watchdog process detects the problem and reboots, and starts cooling again without warning you.
You come home half asleep from a trip eat some food and wind up with food poisoning.
Most users use a firewall to do NAT at the moment., they thus get some level of protection.
Take that away, have loads of IPV6 addresses and un-informed consumers, and your setting yourself up for your uC driven toaster, oven, refrigerator, entertainment center etc spamming people.
It just gives me the screaming heebie-jeebies -- does anyone else remember the feeling of walking into a PeeCee site that was 'internet connected'back in the 90's and asking what they were doing and finding out every un-patched PC had a distinct IP on the internet?
Does anybody know how well Itanium does emulating a RISC ISA like PPC versus CISC ISA like x86? Maybe an Itanium could virtualize a PPC and go at a pretty good clip.
I'm wondering if there is anyone who did an emulator for Alpha VMS binaries for Itanium VMS reading this -- or anyone else who might have an idea.
I looked for SPECFP / SPECINT numbers for 2.7 GHz G5's on spec.org -- but couldn't see them. Does anyone have the numbers so we can validate the '2.7Ghz G5 kicks-butt as is posts?'
--Tarp