Intel details future Larrabee graphics chip
in [Design]
|
Prev: LM3478 design gets insanely hot
Next: 89C51ED2
From: Wilco Dijkstra on 13 Aug 2008 12:24 "Nick Maclaren" <nmm1(a)cus.cam.ac.uk> wrote in message news:g7urac$a3n$1(a)gemini.csx.cam.ac.uk... > > In article <6vBok.60819$Gh7.57365(a)newsfe15.ams2>, > "Wilco Dijkstra" <Wilco.removethisDijkstra(a)ntlworld.com> writes: > |> > |> > |> It's certainly true the C standard is one of the worst specified. However most > |> > |> compiler writers agree about the major omissions and platforms have ABIs that > |> > |> specify everything else needed for binary compatibility (that includes features > |> > |> like volatile, bitfield details etc). So things are not as bad in reality. > |> > > |> > Er, no. I have a LOT of experience with serious code porting, and > |> > am used as an expert of last resort. Most niches have their own > |> > interpretations of C, but none of them use the same ones, and only > |> > programmers with a very wide experience can write portable code. > |> > |> Can you give examples of such different interpretations? There are a > |> few areas that people disagree about, but it often doesn't matter much. > > It does as soon as you switch on serious optimisation, or use a CPU > with unusual characteristics; both are common in HPC and rare outside > it. Note that compilers like gcc do not have any options that count > as serious optimisation. Which particular loop optimizations do you mean? I worked on a compiler which did advanced HPC loop optimizations. I did find a lot of bugs in the optimizations but none had anything to do with the interpretation of the C standard. Do you have an example? > I could send you my Objects diatribe, unless you already have it, > which describes one aspect. You can also add anything involving > sequence points (including functions in the library that may be > implemented as macros), anything involving alignment, when a library > function must return an error (if ever) and when it is allowed to > flag no error and go bananas. And more. You have to give more specific examples of differences of interpretation. I'd like to hear about failures of real software as a direct result of these differences. I haven't seen any in over 12 years of compiler design besides obviously broken compilers. > |> Interestingly most code is widely portable despite most programmers > |> having little understanding about portability and violating the C standard in > |> almost every respect. > > That is completely wrong, as you will discover if you ever need to > port to a system that isn't just a variant of one you are familiar > with. Perhaps 1% of even the better 'public domain' sources will > compile and run on such systems - I got a lot of messages from > people flabberghasted that my C did. 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. > |> Actually you don't need any "autoconfiguring" in C. Much of that was > |> needed due to badly broken non-conformant Unix compilers. I do see > |> such terrible mess every now and again, with people declaring builtin > |> functions incorrectly as otherwise "it wouldn't compile on compiler X"... > > Many of those are actually defects in the standard, if you look more > closely. I did look closely at some of the issues at the time, but they had nothing to do with the standard, it was just working around broken compilers. There is also a lot of software around that blatantly assumes there is a <sys> directory with lots of headers but otherwise doesn't use any POSIX functions. > |> Properly sized types like int32_t have finally been standardized, so the > |> only configuration you need is the selection between the various extensions > |> that have not yet been standardized (although things like __declspec are > |> widely accepted nowadays). > > "Properly sized types like int32_t", forsooth! Those abominations > are precisely the wrong way to achieve portability over a wide range > of systems or over the long term. I shall be dead and buried when > the 64->128 change hits, but people will discover their error then, > oh, yes, they will! Not specifying the exact size of types is one of C's worst mistakes. Using sized types is the right way to achieve portability over a wide range of existing and future systems (including ones that have different register sizes). The change to 128-bit is not going to affect this software precisely because it already uses correctly sized types. > |> > A simple question: have you ever ported a significant amount of > |> > code (say, > 250,000 lines in > 10 independent programs written > |> > by people you have no contact with) to a system with a conforming > |> > C system, based on different concepts to anything the authors > |> > were familiar with? I have. > |> > |> I've done a lot of porting and know most of the problems. It's not nearly > |> as bad as you claim. Many "porting" issues are actually caused by bugs > |> and limitations in the underlying OS. I suggest that your experience is > |> partly colored by the fact that people ask you as a last resort. > > Partly, yes. But I am pretty certain that my experience is a lot > wider than yours. I really do mean different CONCEPTS - start with > IBM MVS and move on to a Hitachi SR2201, just during the C era. It's true that supercomputers of the past had wacky integer sizes and formats or only supported 64-bit int/double and nothing else. But these systems weren't designed to run off-the-shelf C, they were built to run FP code fast (ie. Fortran, not C). In any case I'm pretty certain my experience applies to a much larger market than yours :-) Wilco
From: Wilco Dijkstra on 13 Aug 2008 13:46 "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote in message news:eff30$48a2a587$14802(a)news.teranews.com... > Wilco Dijkstra wrote: >> "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote in message news:55e8e$48a1bebf$4916(a)news.teranews.com... >>> John Larkin wrote: >>>> On Tue, 12 Aug 2008 10:41:23 +0100, "Ken Hagan" >>>> <K.Hagan(a)thermoteknix.com> wrote: >> Exactly. A poor programmer is going to be a poor programmer no matter >> what language they use. It's always fun to see how people believe that >> so called "safe" languages are really a lot "safer". The bugs just move >> elsewhere. > > Not quite. I doubt if a poor programmer could ever get a program to compile with an Ada compiler. Pascal or Modula2 > would protect the world from a lot of the pointer casting disasters that C encourages. I agree C is a bit easier to learn syntactically and so attracts a larger share of bad programmers. But in terms of types there isn't a huge difference - you can't assign incompatible pointers in C without a cast. One issue is that compilers don't give a warning when casts are likely incorrect (such as casting to a type with higher alignment). >> For example garbage collection solves various pointer problems >> that inexperienced programmers make. However it creates a whole new >> set of problems. Or the runtime system or libraries are much bigger and so >> contain their own set of bugs on each platform etc. > > Even experienced programmers can make bad errors with pointers. You could make a fairly strong case for only having > arrays. I doubt it. I've worked for many years on huge applications which use complex data structures with lots of pointers. I've seen very few pointer related failures despite using specialized memory allocators and all kinds of complex pointer casting, unions etc. Most memory failures are null pointer accesses due to simple mistakes. There is certainly a good case for making pointers and arrays more distinct in C to clear up the confusion between them and allow for bounds checking. > Pointers are the programming equivalent of having a rats nest of bare wires randomly soldered to points on your > circuit board with the other end hanging in the air waiting to touch something vital. I guess you don't like pointers then :-) Wilco
From: John Larkin on 13 Aug 2008 13:55 On Wed, 13 Aug 2008 09:18:21 -0700, Joerg <notthisjoergsch(a)removethispacbell.net> wrote: >John Larkin wrote: >> On Tue, 12 Aug 2008 20:50:06 -0700, JosephKK <quiettechblue(a)yahoo.com> >> wrote: >> >>> On Mon, 11 Aug 2008 10:05:01 -0700, John Larkin >>> <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>> >>>> On Mon, 11 Aug 2008 15:00:39 GMT, Jan Panteltje >>>> <pNaonStpealmtje(a)yahoo.com> wrote: >>>> >>>>> On a sunny day (Mon, 11 Aug 2008 07:45:08 -0700) it happened John Larkin >>>>> <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in >>>>> <iij0a4ho0867ufr82loiq6epj3b23u8svr(a)4ax.com>: >>>>> >>>>> >>>>>> I've got a small software project going now to write a new material >>>>>> control/BOM/parts database system. The way I've found to keep the bugs >>>>>> under reasonable control is to use one programmer, one programmer >>>>>> supervisor, and four testers. >>>>>> >>>>>> John >>>>> postgreSQL with phpPgAdmin as frontend here, web based. >>>>> What bugs? Yes the bugs in my SQL :-) >>>> A single database file, of fixed-length records, programmed in >>>> PowerBasic, direct linear search to look things up. Fast as hell and >>>> bulletproof. >>> Only for fairly small numbers of records, not more than a few >>> thousand. Try it with a modest database with say several million >>> records. Big databases have several relational files with over a >>> billion records. Data warehouses hit trillions of records in high >>> tens of thousands of files and more. PowerBasic simply will not scale >>> that high, nor will linear searches. >> >> Right now, we have about 4800 different parts in stock, and about 600 >> parts lists (BOMs). Why use SQL on that? Why make a monster out of a >> simple problem? Searches are so fast you can't see them happen, and >> there's no database maintanance, no linked lists to get tangled, no >> index files. >> > >Way to go. Although Access could also do that with next to nothing in >programming effort. Just set up the fields, some practical queries, the >reports you regularly need, done. We need to do stuff like plan production: enter a list of top assemblies and quantities; look up all the top-level BOMs and break them down; break down all the subassemblies; come up with a total piece-parts count; consider what's in stock, min stock quantities, stuff on order, and decide what we need to buy. And other things that are specific to electronics manufacturing. Most of the commercial packages just don't get it, but they do want nasty license keys, per-seat charges, and annual maintenance costs. I can toss our whole system onto a laptop in 30 seconds and take it with me on a field trip. Just copy the folder and run the single MAX.EXE file. John
From: Wilco Dijkstra on 13 Aug 2008 14:14 "Chris M. Thomasson" <no(a)spam.invalid> wrote in message news:JUEok.11855$i15.2341(a)newsfe01.iad... > "John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message > news:5dg4a4lmj3qtcis1s3prk82aq416l0gaqs(a)4ax.com... >> C is a bad language that has spawned a worse culture. > [...] > > IMHO, C is only as bad as the programmer who uses it... BTW, what you think of C++? The Air Force seems to like it a > lot for systems programming: Exactly. You can write bad software in any language. Most Perl I've seen is far worse than average C. C++ is a lot better than C if you stick to a reasonable subset. The more contentious parts are templates (mainly STL), exceptions and multiple inheritance. > http://www.research.att.com/~bs/JSF-AV-rules.pdf > > I also believe that systems software in the Mars Lander was created in C. C/C++ are widely used in the embedded world including in safety critical systems. Object oriented C++ is even used in most harddrives (they went from 100% assembler to 99% C++ without losing performance) and other realtime systems. Some 13 years ago I wrote software for the Apache helicopter, all in C. What shocked me was not at all the language used but the lack of quality of the hundreds of pages of specifications and the programming capabilities of some collegues. Getting it all working wasn't easy due to the complex and time consuming ISO process used. One of the funny moments was when I spotted 5 mistakes in a 20-line function that calculated the log2 of an integer during a code review. I hope that wasn't their average bugrate! Wilco
From: John Larkin on 13 Aug 2008 14:16
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. We did just such a board recently, 16 channels of analog acquisition, from thermocouples to +-250 volt input ranges, all the standard thermocouple lookup tables, RTD reference junctions, built-in self-test, VME interface. No breadboards, no prototype. The board has 1100 parts and the first one worked. Hardware design works better than software. One reason is that the component interfaces are better defined. Another reason is that we check our work - each other's work - very carefully before we ever try to build it, much less run it. Most engineering - civil, electrical, mechanical, aerospace - works that way. People don't hack jet engine cores and throw them on a test stand to see what blows up. John |