i didn't know Espy all that well, but i'll miss him. from talking to him on irc, i felt he was a very competent, friendly guy. he'll be missed by a lot of people, including all us #mklinux guys. a couple days before the debian 2.2 dedication announcement, i noticed he wasn't in the channel. i was pretty surprised to read about his death (i didn't know he had the disease). i'll miss him. it's strange not seeing '@Espy' in the channel list. it's always sad to lose a developer from the community. rest in peace, Espy.
linux has been running on alpha for YEARS (and ppc, sparc, etc). binary compatibility is not difficult on the same cpu. it's just a matter of linking the foreign binaries against a different libc (or equivilent) that translates syscalls. you really must live in a cave if you think linux only runs on x86 (god what a horrible arch).
this guy is as much of a nut as he claims rms is. when exactly did eric raymond claim that he or anyone else should be free to kill children? that's not only absurd, but it's disonest and misrepressents eric raymond's views. i actually thought the article raised some very good points, but i just had to stop reading when he started to rant a bunch of anti-gun stuff (especially, implying that access to guns makes people more violent, which is easly proven untrue by that fact that other countries, where civilian gun ownership is allowed, have LESS violence than the US). instead of arguing against some free software / open source views, he's arguing against rms and eric raymond. it's too bad it was ruined by offtopic rants and hypocritical views.
you need to review you reading comprehension skills. notice the comma, that seperates the two halves of the sentence. no where in that sentence does it say only militia members may be armed.
it's egcs (pronounced egcs), not egcc. egcs was not created to add x86 optimizing, it was forked cuz the egcs people felt the gcc maintainers were too slow at intergrating patches (fwih). pgcc was started (i believe) for the soul purpose of optimizing for x86 cpus, at the expense of other archs.
the compiler had to be built for alpha, or it won't produce alpha binaries. also, the 64bit nature of alphas just means gprs are 64bits wide, as are virtual addresses. trust me, gcc uses the fpu on alphas. if it didn't, fp ops would have to be emulated, which is EXTREMELY slow.
i'd guess scheduling is the major reason ccc outpreforms gcc. please correct me, if i'm wrong about gcc having ev6-specific scheduling.
it's not just alpha users who can't use it, it's also ppc and everything else. it's only of use to linux/x86 users and even then it has all the issues related to being closed (can't improve it, compatability, etc).
(yeah, i know this post is redundent, but i wanted to spell out big problem with binary only distrobution.)
CISC instructions (fwik) rarely do more than comparable RISC ops. example: x86 mov will do register load/stores and mem->mem copies, but it can't do all at once. the reason x86 code is smaller is due to its variable opcode length. the fact that x86 ops can each do more than one job is just namespace (opcode) compression, and it necessitates microcode and complicates pipelining.
ignoring the "real time" part of the question (which, btw, doesn't make much sense), you'd better off with just about anything else other than x86. i'd say try out a 264 alpha (eg, compaq's alpha testdrive program) and if appropiate for the type of math you're doing, try coding it for altivec on a g4. altivec and alpha would be your best bets.
VLIW/EPIC is a BAD idea. i'm not sure what you mean by "schedulers in RISC chips having trouble keeping up". VLIW is a crippled architechture; no runtime scheduling, only static compile time (note that i'm ignoring majc+java right now -- majc is actually a very interesting arch). also, ia-64 is seriously flawed, in that it directly exposes the implementation to the isa (that's just one of many bad design decisions with ia-64, though).
the majority of posix-compliant/unix-like OSs are NOT microkernels. {net,free,open}bsd isn't and neither are linux, aix, solaris, hpux, irix, and just about every other unix-like kernel. the only microkernel unix-like kernels i can think of are qnx, mklinux, minix, and mac os x.
i've got an old 20meg corvus here (for apple//s) that has a video backup card plugged into the backplate that has a composite video out. other vendors also sold ntsc backup systems.
the serial ports are zilog's (the same as used on sun hardware) and their specs are definetly NOT secret (since all the open source oses i know have drivers for them, and also, amd's site has docs for their 8350 clones). also, this whole thing about apple keeping their hardware secret is simply not true anyway. i don't know why people continue to think it is. for those that don't know, apple has a full time employee who's job it is to help developers get hardware specs (and has been doing so for a while now).
it's hard for me to find words for how utterly stupid and unbelievible(sp) this is. i hope this never EVER comes to my state (virginia). i absolutely guarranty(sp) this WILL be cracked. it's only a matter of time before someone finds the weaknesses and exploits them to elect whoever they want. accurate vote talling EXTREMELY important. hopefully, laws will be passed to make online voting illegal. this is truely beyond stupid.
nitpick: 64bit registers don't give you more bandwidth. i think you're thinking of the system bus. 64bit registers eat cache, but are great for long longs.
those proms don't vialilate(yeah, yeah, sp) any pci spec and there's nothing stopping you from putting one in an x86 box. the prom contains arch independant forth drivers (as do mac cards) instead of arch dependent x86 bios drivers (which are why there are x86 real mode emulators for ppc and alpha).
Slashdot Mirror
i didn't know Espy all that well, but i'll miss him. from talking to him on irc, i felt he was a very competent, friendly guy. he'll be missed by a lot of people, including all us #mklinux guys. a couple days before the debian 2.2 dedication announcement, i noticed he wasn't in the channel. i was pretty surprised to read about his death (i didn't know he had the disease). i'll miss him. it's strange not seeing '@Espy' in the channel list. it's always sad to lose a developer from the community. rest in peace, Espy.
if i had only seen the question, i could have rented the movie, tried to figure it out, THEN read the answer! now it's no fun!
repeat this to yourself: BOGOMIPS ARE MEANINGLESS
they are in NO way a measure of preformance. it is nothing more than an empty delay loop.
linux has been running on alpha for YEARS (and ppc, sparc, etc). binary compatibility is not difficult on the same cpu. it's just a matter of linking the foreign binaries against a different libc (or equivilent) that translates syscalls. you really must live in a cave if you think linux only runs on x86 (god what a horrible arch).
i've playing mpegs for years on ppc linux. this isn't news.
this guy is as much of a nut as he claims rms is. when exactly did eric raymond claim that he or anyone else should be free to kill children? that's not only absurd, but it's disonest and misrepressents eric raymond's views. i actually thought the article raised some very good points, but i just had to stop reading when he started to rant a bunch of anti-gun stuff (especially, implying that access to guns makes people more violent, which is easly proven untrue by that fact that other countries, where civilian gun ownership is allowed, have LESS violence than the US). instead of arguing against some free software / open source views, he's arguing against rms and eric raymond. it's too bad it was ruined by offtopic rants and hypocritical views.
any properly written code will compile on any arch.
i always find it funny that the capital of the country which has a right to bear arms in it's constitution, violates that very right.
you need to review you reading comprehension skills. notice the comma, that seperates the two halves of the sentence. no where in that sentence does it say only militia members may be armed.
the finger protocol is not the same as http. try finger://
it produces a weird phasing effect that's annoying as hell. i have to cut 6k and above just to make it bearable. 56kps would be nice.
the compiler had to be built for alpha, or it won't produce alpha binaries. also, the 64bit nature of alphas just means gprs are 64bits wide, as are virtual addresses. trust me, gcc uses the fpu on alphas. if it didn't, fp ops would have to be emulated, which is EXTREMELY slow.
i'd guess scheduling is the major reason ccc outpreforms gcc. please correct me, if i'm wrong about gcc having ev6-specific scheduling.
it's not just alpha users who can't use it, it's also ppc and everything else. it's only of use to linux/x86 users and even then it has all the issues related to being closed (can't improve it, compatability, etc).
(yeah, i know this post is redundent, but i wanted to spell out big problem with binary only distrobution.)
heh, make what you will of this, but here's a /wi mafiaboy from efnet at about 1:15am 4/20 edt. me, i'm going to sleep.
ÚÄ Ä Ä Ä ÄÄÚÄÄÄÄ Ä Ä Ä ÄÄ ÄÄ Ä
[mafiaboy.] (7777777@HSE-Toronto-ppp95609.sympatico.ca) [Canada ]
[ircname..] AODiSO-iCOiSO-HERITAGE-RTS-KNiFE-CADMiUM
[channels.] #irc.core.com #kznetworks #syndicate99
[server...] irc.nethead.com ([207.246.129.125] DOWN WITH PANTS)
ÀÄ ÄÄ Ä ÄÄÄÙÀÄÄÄÄÄÄÄ Ä ÄÄÄ
CISC instructions (fwik) rarely do more than comparable RISC ops. example: x86 mov will do register load/stores and mem->mem copies, but it can't do all at once. the reason x86 code is smaller is due to its variable opcode length. the fact that x86 ops can each do more than one job is just namespace (opcode) compression, and it necessitates microcode and complicates pipelining.
god i loved that game (in addition to trade wars 2002, and the original TW). and don't forget the pit and netrunner.
ignoring the "real time" part of the question (which, btw, doesn't make much sense), you'd better off with just about anything else other than x86. i'd say try out a 264 alpha (eg, compaq's alpha testdrive program) and if appropiate for the type of math you're doing, try coding it for altivec on a g4. altivec and alpha would be your best bets.
VLIW/EPIC is a BAD idea. i'm not sure what you mean by "schedulers in RISC chips having trouble keeping up". VLIW is a crippled architechture; no runtime scheduling, only static compile time (note that i'm ignoring majc+java right now -- majc is actually a very interesting arch). also, ia-64 is seriously flawed, in that it directly exposes the implementation to the isa (that's just one of many bad design decisions with ia-64, though).
actually, the altivec vector units can do quite a bit. 160 instructions, iirc.
the majority of posix-compliant/unix-like OSs are NOT microkernels. {net,free,open}bsd isn't and neither are linux, aix, solaris, hpux, irix, and just about every other unix-like kernel. the only microkernel unix-like kernels i can think of are qnx, mklinux, minix, and mac os x.
i've got an old 20meg corvus here (for apple //s) that has a video backup card plugged into the backplate that has a composite video out. other vendors also sold ntsc backup systems.
the serial ports are zilog's (the same as used on sun hardware) and their specs are definetly NOT secret (since all the open source oses i know have drivers for them, and also, amd's site has docs for their 8350 clones). also, this whole thing about apple keeping their hardware secret is simply not true anyway. i don't know why people continue to think it is. for those that don't know, apple has a full time employee who's job it is to help developers get hardware specs (and has been doing so for a while now).
it's hard for me to find words for how utterly stupid and unbelievible(sp) this is. i hope this never EVER comes to my state (virginia). i absolutely guarranty(sp) this WILL be cracked. it's only a matter of time before someone finds the weaknesses and exploits them to elect whoever they want. accurate vote talling EXTREMELY important. hopefully, laws will be passed to make online voting illegal. this is truely beyond stupid.
nitpick: 64bit registers don't give you more bandwidth. i think you're thinking of the system bus. 64bit registers eat cache, but are great for long longs.
those proms don't vialilate(yeah, yeah, sp) any pci spec and there's nothing stopping you from putting one in an x86 box. the prom contains arch independant forth drivers (as do mac cards) instead of arch dependent x86 bios drivers (which are why there are x86 real mode emulators for ppc and alpha).