Re: Intel details future Larrabee graphics chip

I like pencil and paper too.

I'd like to see you run a spice simulation on an HP-35!

Regards, Martin Brown

** Posted from **

The first sim I ever ran was of a steamship throttle control system, run on the HP9100 programmable desktop calculator, the predecessor to the HP35. I soon moved it to a PDP-8 running Focal, so I could plot the loop step responses on the teletype. We got a *lot* of business, maybe $100M, from those simulations.

I was recently coding a serial-input interrupt service routine in 68K assembly. It does a bunch of character editing and handles a few special cases... it presents a cleaned-up command string and a ready flag to the mainline loop, which does other stuff in addition to checking for serial commands and parsing/executing. It's only a page of code, but I had to draw it (yes, on D-size vellum) to really get it right. The paths turned out to look really strange. I reference the numbered drawing in the code, and will include a jpeg with the program source when it's formally released.

We don't need no stinkin' RTOS!

Another difference between engineers and programmers is that engineering tends to be visual/parallel and programming tends to be textual/sequential. It's fun to watch programmer types attack a logic HDL; everything happens everywhere, all at once!

John

His work was significantly more disciplined when he worked for DEC than what was the result from Redmond. But he didn't have a choice: Backward compatibility, bug for bug and misfeature for misfeature, rule(d|s) supreme in the Windows realm.

Jan

In article , =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= writes: |> |> > That's not what happened. They hired David Cutler from DEC, where he |> > had worked on VMS, and pretty much left him alone. The chaos was and |> > is part of the culture of modern programming. |> |> His work was significantly more disciplined when he worked for DEC than |> what was the result from Redmond. But he didn't have a choice: Backward |> compatibility, bug for bug and misfeature for misfeature, rule(d|s) |> supreme in the Windows realm.

Oh, it was worse than that! After he had done the initial design (which was reasonable, if not excellent), he was elbowed out, and half of his design was thrown out to placate the god Benchmarketing.

The aspect that I remember was that the GUI was brought back from where he had exiled it to the 'kernel' - and, as we all know, the GUIs are the source of all ills on modern systems :-(

Regards, Nick Maclaren.

;^(...

They had special flags for running specific applications that tuned the API bug set so the major apps could still run.

That did confuse me a little. The book has him holding out, against Gates even, for a small kernel with a client-server relationship to everything else, including all the graphics. The story ends happily there, with nothing left to do but fix the circa 1000 bugs initially shipped. I suppose the kernel was trashed/bloated later in the name of speed.

John

In article , John Larkin writes: |> |> That did confuse me a little. The book has him holding out, against |> Gates even, for a small kernel with a client-server relationship to |> everything else, including all the graphics. The story ends happily |> there, with nothing left to do but fix the circa 1000 bugs initially |> shipped. I suppose the kernel was trashed/bloated later in the name of |> speed.

Right in one - at least according to my understanding!

I read the book, and felt that is was a significant advance, though not as far as the best of the research systems (e.g. the Cambridge CHAOS system on CAP).

Regards, Nick Maclaren.

Yep - I think that was part of the 3.51 to 4.0 transition. As I understand it, the thing was just too resource-hungry for the hardware of the day to be marketable in that state.

But in addition, there were things like not checking syscall arguments in the kernel - something the VMS guys had been religous about. It was only after people came out with a CRASHME variant that MS was shamed into fixing those, for instance. That really shows their lack of discipline.

Jan

In article , =?ISO-8859-15?Q?Jan_Vorbr=FCggen?= writes: |> |> > Oh, it was worse than that! After he had done the initial design |> > (which was reasonable, if not excellent), he was elbowed out, and |> > half of his design was thrown out to placate the god Benchmarketing. |> > |> > The aspect that I remember was that the GUI was brought back from |> > where he had exiled it to the 'kernel' - and, as we all know, the |> > GUIs are the source of all ills on modern systems :-( |> |> Yep - I think that was part of the 3.51 to 4.0 transition. As I |> understand it, the thing was just too resource-hungry for the |> hardware of the day to be marketable in that state.

As I heard it, that was as much an excuse as a reason. What I heard was that it did perform like a dog, but that didn't distinguish it from any of the other major releases. And that problem was temporary.

The other reason I heard was that the GUI (and other components?) were so repulsive that moving all of their privileged actions to the other side of an interface (ANY interface) was beyond the programmers. But they didn't want to admit that, so they mounted an internal propaganda campaign about the performance.

However, you know what such stories are like. I neither believe nor disbelieve it.

Regards, Nick Maclaren.

a lot of gates),

Unless you blur the boundary further by using on-the-fly reprogrammable gate arrays.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

On some machines the high-order bit is shifted out, on others (e.g. S/

370) it remains unchanged: 0x80000001

Thanks, I've received it, I'll have a look at it soon (it's big...).

My point is that such weird systems no longer get designed. The world has standardized on 2-complement, 8-bit char, 32-bit int etc, and that is unlikely to change. Given that there isn't much variation possible.

Putting in extra effort to allow for a theoretical system with sign-magnitude

5-bit char or a 31-bit one-complement int is completely insane.

It's only source-to-source optimizers that might need to consider these issues, but these are very rare (we bought one of the few still available).

Most compilers, including the highly optimizing ones, do almost all optimization at a far lower level. This not only avoids most of the issues you're talking about, but it also ensures badly behaved programs are correctly optimized, while well behaved programs are still optimized aggressively.

S370, Alpha and PA-RISC all support arithmetic right shifts. There is no information available on the S-3600.

No. The standard is quite explicit that any left shift of a negative value is undefined, even if they there is no overflow. This is an inconsistency as compilers change multiplies by a power of 2 into a left shift and visa versa. There is no similar undefined behaviour for multiplies however.

of

You're missing the point. A theoretical 64-bit CPU that only supports

64-bit operations could emulate support for 8-bit char, 16-bit short, 32-bit int. Without such emulation it would need 64-bit char, 128-bit short/int, 256-bit int/long in order to support C. Alpha is proof this is perfectly feasible: the early versions emulated 8/16-bit types in software without too much overhead.

Once we agree that it is feasible to emulate types, it is reasonable to mandate that each implemenation supports the sized types.

Wilco

inputs or when rounding the actual fp

implementation, but otherwise it should

that is set.

result + 1.

mask

to work

then deleted as it didn't really add to my

use a hardware bitscan opcode.

I like the lookup in a register method. I once did something like this:

uint8 table[32] = { ... };

int log2_floor(unsigned x) { if (x == 0) return -1; x |= x >> 1; x |= x >> 2; x |= x >> 4; x |= x >> 8; x |= x >> 16; x *= 0x... // multiply with magic constant return table[x >> 27]; // index into table }

The shifted OR's force all bits after the leading one to be set too. This reduces the number of possibilities to just 32. The multiply then shifts the magic constant by N bits. It is chosen so that the top 5 bits end up containing a unique bitpattern for each of the 32 possible values of x. It took 10 instructions plus 32 bytes of table. Placing the table immediately after the return instruction allowed the use of the LDRB r0,[PC,r0,LSR #27] instruction, so it didn't even need an instruction to create the table address...

Wilco

It would be correct as long as there is no overflow. Ie. 0xffffffff

messagenews:g81arl$6a0$ snipped-for-privacy@gemini.csx.cam.ac.uk...

Byte addressability is still uncommon in DSP world. And no, C compilers for DSPs do not emulate char in a manner that you suggested below. They simply treat char and short as the same thing, on 32-bit systems char, short and long are all the same. I am pretty sure that what they do is in full compliance with the C standard.

Agreed

It seems you overlooked the main point of Nick's concern - sized types prevent automagical forward compatibility of the source code with larger problems on bigger machines.

To be fair to Wilco, I think that even the DSP world has been moving more in the direction of idiomatic C support for the last decade or so. The TI-C6000 series are all byte-addressable 32-bit systems for exactly that reason. The poster child for char/short/int/long=32 bit was probably the TI-C3x and C4x families, and they're not much used any more, I think. SHARC is in that boat, but is still used a fair bit. The WE-DSP32C was a

32-bit float DSP with byte addressability some 20 years ago, so it's not that new an idea.

I doubt that anyone would design a new DSP architecture these days that didn't have good (i.e., idiomatic) C support, unless it's something a bit peculiar, like the TAS3108, which is not expected to have C support at all.

Cheers,

--
Andrew

Do you know if this is true of the 16-bitters as well? Last time I used TI's C54x family of (16-bit) DSP, all data types were... 16 bits.

Some years ago I used the TI GSP (graphical signal processor) 34020. Given the graphical orientation, data addresses were *bit* addresses -- it was perfectly happy to add, e.g., 16 bits somewhere in the middle of 4 bytes to 16 bits completely "misaligned" in some other set of 4 bytes. Fun to play around with, although as one would expect performance was better when everything was algined.

Sure, they're all fairly pure 16-bitters. I wouldn't call them new architectures, though, which is what I was getting at. The FreeScale

56k3 series are still 24-bit word addressed too, but I'm not counting those as modern, either.

For "modern", besides the C6000 series, I'd include the ADI/Intel Blackfin and the VLSI ZSP series. I haven't used either of those in anger, but I believe that they're both more-or-less "C" compliant. The main other "newness" in DSP-land are all of the DSP-augmented RISC processors, and they're all essentially pure "C" machines, too (alignment issues can be worse though, and you often have to use asm or intrinsics to get at the DSP features.)

Not the 34010? I don't remember hearing about an 020 version.

Apart from the 8-times worse fan-out of the multiplexers, which might limit clock speed, I don't really see how this would be much worse than unaligned byte-addressed operations. I don't think that there are too many people interested in single-bit-deep graphics systems any more, though.

Cheers,

--
Andrew

Ah, gotcha.

I've looked a little at the Blackfin for an upcoming project, and it looks pretty nice as far as I can tell.

Yep, there was a 34020 (the board I used paired a 34020 GSP with a 320C40 DSP... it wasn't uncommon that we confused the chip numbers!).

I don't think it was any worse than that, but still a significant penalty for people looking for the ultimate in speed. (The thing ran at all of... 40MHz, perhaps? ...seemed fast at the time...)

Yep, at least not by the time you hit QVGA or higher resolutions.

---Joel