Intel details future Larrabee graphics chip
in [Design]
|
Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Nick Maclaren on 14 Aug 2008 09:10 In article <V4Uok.4995$Od3.4795(a)newsfe28.ams2>, "Wilco Dijkstra" <Wilco.removethisDijkstra(a)ntlworld.com> writes: |> |> I'd certainly be interested in the document. My email is above, just make |> the obvious edit. Sent. |> > |> 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. |> It's only when you implement the standard you realise many of the issues are |> irrelevant in practice. Take sequence points for example. They are not even |> modelled by most compilers, so whatever ambiguities there are, they simply |> cannot become an issue. They are relied on, heavily, by ALL compilers that do any serious optimisation. That is why I have seen many problems caused by them, and one reason why HPC people still prefer Fortran. |> Similarly various standard pendantics are moaning |> about shifts not being portable, but they can never mention a compiler that |> fails to implement them as expected... Shifts are portable if you code them according to the rules, and don't rely on unspecified behaviour. I have used compilers that treated signed right shifts as unsigned, as well as ones that used only the bottom 5/6/8 bits of the shift value, and ones that raised a 'signal' on left shift overflow. There are good reasons for all of the constraints. No, I can't remember which, offhand, but they included the ones for the System/370 and Hitachi S-3600. But there were also some microprocessor ones - PA-RISC? Alpha? |> Btw Do you happen to know the reasoning behind signed left shifts being |> undefined while right shifts are implementation defined. Signed left shifts are undefined only if they overflow; that is undefined because anything can happen (including the CPU stopping). Signed right shifts are only implementation defined for negative values; that is because they might be implemented as unsigned shifts. |> It will work as long as the compiler supports a 32-bit type - which it will of |> course. But in the infinitesimal chance it doesn't, why couldn't one |> emulate a 32-bit type, just like 32-bit systems emulate 64-bit types? Because then you can't handle the 64-bit objects returned from the library or read in from files! Portable programs will handle whatever size of object the system supports, without change - 32-bit, 64-bit, 48-bit, 128-bit or whatever. |> Actually various other languages support sized types and most software |> used them long before C99. In many cases it is essential for correctness |> (imagine writing 32 bits to a peripheral when it expects 16 bits etc). So |> you really have to come up with some extraordinary evidence to explain |> why you think sized types are fundamentally wrong. Not at all. That applies ONLY to the actual external interface, and Terje and I have explained why C fixed-size types don't help. Regards, Nick Maclaren.
From: John Larkin on 14 Aug 2008 10:08 On Thu, 14 Aug 2008 11:00:02 +0100, Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote: >John Larkin wrote: >> On Wed, 13 Aug 2008 10:40:47 +0100, Martin Brown >> <|||newspam|||@nezumi.demon.co.uk> wrote: >> >> >>>> I read that for a major bunch of Windows APIs, the only documantation >>>> was the source code itself. > >>> That is probably slightly unfair (but also partly true). It was the >>> unruly Windows message API that eventually killed the strongly typed >>> language interface for me. Just about every message was a pointer to a >>> "heaven knows what object" that you had to manually prod and probe at >>> runtime to work out its length and then what it claimed to be. >>> Maintaining the string typed interface definitions even with tools >>> became too much of a chore. >>> >>> Imagine doing electronics where all components are uniform sized and >>> coloured and you have to unpeel the wrapper to see what is inside. Worse >>> still some of them may contain uninitialised pointers if you are >>> unlucky, or let you write off the end of them with disastrous results. >> >> Hardware design keeps moving up in abstraction level too. I used to >> design opamps and voltage regulators out of transistors. Now I'm >> dropping sixteen isolated delta-sigma ADCs around an FPGA that talks >> to a 32-bit processor. That's sort of equivalent to building a >> software system using all sorts of other people's subroutines. > >Libraries do exist in software too and some of them are very good. A lot >of code reuse projects do fail because the gatekeeper is pressurised to >put things in that are not of the required standard for reuse. I recall >one that was called the suppository by the engineers ordered to use it. > >Using off the shelf reliable software components and making a living >selling them has not taken off the way it should have. Generally you >have to buy a whole library and licence. > >And remember that your hardware design is done on a software tool... Yes, I'm a great fan of design automation... ftp://66.117.156.8/Auto.jpg John
From: Martin Brown on 14 Aug 2008 10:52 John Larkin wrote: > On Thu, 14 Aug 2008 11:00:02 +0100, Martin Brown > <|||newspam|||@nezumi.demon.co.uk> wrote: > >> John Larkin wrote: >>> On Wed, 13 Aug 2008 10:40:47 +0100, Martin Brown >>> <|||newspam|||@nezumi.demon.co.uk> wrote: >>> >> And remember that your hardware design is done on a software tool... > > Yes, I'm a great fan of design automation... > > ftp://66.117.156.8/Auto.jpg 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 http://www.teranews.com **
From: John Larkin on 14 Aug 2008 11:24 On Thu, 14 Aug 2008 15:52:23 +0100, Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote: >John Larkin wrote: >> On Thu, 14 Aug 2008 11:00:02 +0100, Martin Brown >> <|||newspam|||@nezumi.demon.co.uk> wrote: >> >>> John Larkin wrote: >>>> On Wed, 13 Aug 2008 10:40:47 +0100, Martin Brown >>>> <|||newspam|||@nezumi.demon.co.uk> wrote: >>>> >>> And remember that your hardware design is done on a software tool... >> >> Yes, I'm a great fan of design automation... >> >> ftp://66.117.156.8/Auto.jpg > >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 http://www.teranews.com ** 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
From: Jan Vorbrüggen on 15 Aug 2008 09:39
> 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. Jan |