Intel details future Larrabee graphics chip
in [Design]
|
Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Wilco Dijkstra on 18 Aug 2008 18:36 "Michel Hack" <hack(a)watson.ibm.com> wrote in message news:a9666a40-b8d3-454b-91ca-1ca13734ff5c(a)k37g2000hsf.googlegroups.com... > On Aug 13, 5:52 pm, "Wilco Dijkstra" > <Wilco.removethisDijks...(a)ntlworld.com> wrote: > >> Btw Do you happen to know the reasoning behind signed left shifts being >> undefined while right shifts are implementation defined? > > On some machines the high-order bit is shifted out, on others (e.g. S/ > 370) > it remains unchanged: 0x80000001 << 1 can become 0x80000002 and > not 0x00000002 in a 32-bit register. The S/370 way parallels the > common > sign-propagation method of arithmetic right shifts: the sign does not > change. It would be correct as long as there is no overflow. Ie. 0xffffffff << 1 becomes 0xfffffffe as epected. It's only when you have overflow that things are different (for both positive and negative signed numbers). The obvious implementation of left shift on one complement and sign magnitude systems also work as expected. So it looks the C standard is incorrect here. Wilco
From: already5chosen on 18 Aug 2008 19:54 On Aug 18, 11:46 pm, "Wilco Dijkstra" <Wilco.removethisDijks...(a)ntlworld.com> wrote: > "Nick Maclaren" <n...(a)cus.cam.ac.uk> wrote in messagenews:g81arl$6a0$1(a)gemini.csx.cam.ac.uk... > > > In article <V4Uok.4995$Od3.4...(a)newsfe28.ams2>, > > "Wilco Dijkstra" <Wilco.removethisDijks...(a)ntlworld.com> writes: > > |> > > |> I'd certainly be interested in the document. My email is above, just make > > |> the obvious edit. > > > Sent. > > Thanks, I've received it, I'll have a look at it soon (it's big...). > > > |> > |> I bet that most code will compile and run without too much trouble. > > |> > |> C doesn't allow that much variation in targets. And the variation it > > |> > |> does allow (eg. one-complement) is not something sane CPU > > |> > |> designers would consider nowadays. > > |> > > > |> > The mind boggles. Have you READ the C standard? > > |> > > |> More than that. I've implemented it. Have you? > > > Some of it, in an extremely hostile environment. However, that is a lot > > LESS than having written programs that get ported to radically different > > systems - especially ones that you haven't heard of when you wrote the > > code. And my code has been so ported, often without any changes needed. > > 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. > 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. > 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. > Agreed <snip> > > Once we agree that it is feasible to emulate types, it is reasonable to > mandate that each implemenation supports the sized types. > > Wilco 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.
From: Andrew Reilly on 18 Aug 2008 22:34 On Mon, 18 Aug 2008 16:54:30 -0700, already5chosen wrote: >> 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. >> >> > 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. 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
From: Joel Koltner on 18 Aug 2008 23:40 "Andrew Reilly" <andrew-newspost(a)areilly.bpc-users.org> wrote in message news:6gupq5Fhir3sU2(a)mid.individual.net... > 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. 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. > The WE-DSP32C was a > 32-bit float DSP with byte addressability some 20 years ago, so it's not > that new an idea. 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.
From: Andrew Reilly on 19 Aug 2008 00:14
On Mon, 18 Aug 2008 20:40:43 -0700, Joel Koltner wrote: > "Andrew Reilly" <andrew-newspost(a)areilly.bpc-users.org> wrote in message > news:6gupq5Fhir3sU2(a)mid.individual.net... >> 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. > > 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. 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.) >> The WE-DSP32C was a >> 32-bit float DSP with byte addressability some 20 years ago, so it's >> not that new an idea. > > Some years ago I used the TI GSP (graphical signal processor) 34020. Not the 34010? I don't remember hearing about an 020 version. > 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. 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 |