Actually, throwing all sorts of stuff in the SoC is rather wasteful. Just figure out what the sort of processing loads it's gonna see, and how much, put in appropriate co-processors. In this case, a descent general purpose dataflow architecture vector co-processor ought to do it. You can offload networking, graphics, storage/compression, crypto... That's a lot of shit.
Precisely. I'd say the prettiest assembler these days belongs to MIPS and SPARC, and maybe the Alpha (these days — ROFL), but I've never gotten lower than C, I just dabble, so I'm not an authority. OK, dabble a lot.
Actually a LGPL-like variant of CDDL and/or with GPL v.2 exception clauses, with some Anti-DRM measures from GPL v.3 would be just what the doctor ordered for a non-fractured community. Possibly with LaTeX license clauses. I'm completly serious. Also, could somebody explain the above joke? I only understood parts of it.
Yeah, right. I agree, x86 is crap, but ARM ain't any better, it's like five or 6 ISAs have been dropped on the same die. The only good parts are mostly inside, except for the cool IF instruction that saves a lot of branching. I wonder if someone will get rid of the cruft, and add a do instruction that performs an instruction from memory without flushing the pipeline...</tangent>
Solaris runs on mainframes? That's bigger news. I thought the POWER port is still in development. Either that, or you are playing fast and loose with the term "mainframe".
What IDE interface? SD is a separate protocol, incompatible with PATA/IDE. I think you are thinking of CF. That's basically PATA with a wire adapter. As is PCMCIA, without the Card[Bus]/[Bay] extensions. </interconnect geek>
PDF is an open format, can't someone just make a descent reader, with the aforementioned features? Doesn't sound technically challenging, you just have to tweak the PostScript interpreter. Then again, that's probably why nobody has bothered...
Who is the nitwit writing assembly for a game, and using direct hardware access? They sure don't give a shit what the hardware is on a PC, yet PC games handle well. As for power, just build for the lowest reasonable common denominator.
I though barrel processors (multiple hardware threads per core) were supposed to cure the problem of pipeline stalls, since in a n-way CPU, the 1 clock-cycle goes to the first virtual core, the second to the second virtual core, up until the n-th thread and core. Even if a pipeline stall occurs in a virtual core, the adjacent clock cycles aren't wasted. That's what Intel probably had in mind with Hyperthreading, but the software world wasn't (isn'?) ready for it.
I though the SPEs to the PPC core were suposed to be the on-chip GPGPU. They are general purpose vector co-processors, while GPUs are specialized ones. Am I missing something?
And this, children, is a person who doesn't use his on-board audio with headphones, and has not built fanless systems with noisy motherboards... Or had to deal with BSODs and data corruption not from faulty RAM or CPU, or PSU, but from a crappy FSB for Pete's sake!
Slashdot Mirror
42 minute meetings FTW!
Actually, throwing all sorts of stuff in the SoC is rather wasteful. Just figure out what the sort of processing loads it's gonna see, and how much, put in appropriate co-processors. In this case, a descent general purpose dataflow architecture vector co-processor ought to do it. You can offload networking, graphics, storage/compression, crypto... That's a lot of shit.
Bullshit, DEC Alpha trounces PowerPC every time.
Why is this funny? More like insightful.
Beautiful argument. Mod parent up.
Precisely. I'd say the prettiest assembler these days belongs to MIPS and SPARC, and maybe the Alpha (these days — ROFL), but I've never gotten lower than C, I just dabble, so I'm not an authority. OK, dabble a lot.
Actually a LGPL-like variant of CDDL and/or with GPL v.2 exception clauses, with some Anti-DRM measures from GPL v.3 would be just what the doctor ordered for a non-fractured community. Possibly with LaTeX license clauses. I'm completly serious. Also, could somebody explain the above joke? I only understood parts of it.
<xml><Theo De Raat><joke>Shut up, Linus, go break your drivers again or something.</joke></Theo De Raat></xml>
Yeah, right. I agree, x86 is crap, but ARM ain't any better, it's like five or 6 ISAs have been dropped on the same die. The only good parts are mostly inside, except for the cool IF instruction that saves a lot of branching. I wonder if someone will get rid of the cruft, and add a do instruction that performs an instruction from memory without flushing the pipeline...</tangent>
.. of Social Graces
Learn to read please.
That is a separate issue, and something easily fixable, even with macros.
array_push ($myarray, $myvalue)
That good enough? Valid PHP, IIRC.
With in-line COBOL, FORTRAN and ALGOL 68, COMEFROM statements, passing labels as arguments, ActionScript and APL for flow control, and lots of ALTER.
Solaris runs on mainframes? That's bigger news. I thought the POWER port is still in development. Either that, or you are playing fast and loose with the term "mainframe".
What IDE interface? SD is a separate protocol, incompatible with PATA/IDE. I think you are thinking of CF. That's basically PATA with a wire adapter. As is PCMCIA, without the Card[Bus]/[Bay] extensions. </interconnect geek>
For now. That's an open niche to be filled by the free market. Any takers?
Isn't it ironic that a M$ format, .chm, is the only (?) realistic choice for an e-book format. and it wasn't meant for that, either...
PDF is an open format, can't someone just make a descent reader, with the aforementioned features? Doesn't sound technically challenging, you just have to tweak the PostScript interpreter. Then again, that's probably why nobody has bothered...
Yeah!...Wait, I was supposed to disagree?...
Who is the nitwit writing assembly for a game, and using direct hardware access? They sure don't give a shit what the hardware is on a PC, yet PC games handle well. As for power, just build for the lowest reasonable common denominator.
+1 Johnny Bravo Reference?
make me hungry for bacon & eggs.
bacon => pig => swine => swine flu => bird flu => chicken => egg =>
|^|<-----------ignorethisnotice-----------ignorethisnotice-------------ignorethisnotice
=> egg => chicken => bird => bird flu => swine flu => pig => bacon |^|
FTFY.
I though barrel processors (multiple hardware threads per core) were supposed to cure the problem of pipeline stalls, since in a n-way CPU, the 1 clock-cycle goes to the first virtual core, the second to the second virtual core, up until the n-th thread and core. Even if a pipeline stall occurs in a virtual core, the adjacent clock cycles aren't wasted. That's what Intel probably had in mind with Hyperthreading, but the software world wasn't (isn'?) ready for it.
I though the SPEs to the PPC core were suposed to be the on-chip GPGPU. They are general purpose vector co-processors, while GPUs are specialized ones. Am I missing something?
And this, children, is a person who doesn't use his on-board audio with headphones, and has not built fanless systems with noisy motherboards...
Or had to deal with BSODs and data corruption not from faulty RAM or CPU, or PSU, but from a crappy FSB for Pete's sake!