RISC load-store verses x86 Add from memory.
|
From: Terje Mathisen "terje.mathisen at on 27 Jun 2010 16:04 Andy 'Krazy' Glew wrote: > On 6/26/2010 12:55 PM, Terje Mathisen wrote: >> Anton Ertl wrote: >>> But of course, all of this is outside the standardized subset of C. >> >> In my not so humble opinion, this is simply broken. > > What is broken? The code snippets, or the fact that this is outside the > standard subset of C? The latter: Currently the C standard is more or less useless for signed variables. :-( Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen "terje.mathisen at on 27 Jun 2010 16:11 MitchAlsup wrote: > On Jun 26, 9:07 pm, Andy 'Krazy' Glew<ag-n...(a)patten-glew.net> wrote: >> int >> read(int d, char *buf, int nbytes) >> DESCRIPTION >> >> Read() attempts to read nbytes of data from the object referenced by the file descriptor d into the buffer pointed to by >> buf. >> >> RETURN VALUES >> >> If successful, the number of bytes actually read is returned. Upon reading end-of-file, zero is returned. Otherwise, a >> -1 is returned and the global variable errno is set to indicate the error..- Hide quoted text - > > Clearly this is a case where an int is required by the library > definition and similar definitions hold for argc,... > My argument is not directed towards these, but after the code checks > for error conditions (negative values), many times you will be better > off assigning the now known to be positive value to an unsigned for > future use. > So the use code might look something like: > > { signed long int readc; > unsigned long int index; > readc = read(infile, inbuf, InBufMAX); > if( readc>=0 ) > { > for( index=0; index< readc; index++) > // readc is known to be non-negative Ouch! I hope I never do it that way, I much prefer to do a single conversion (copy/typecast/whatever) as soon as I know that the value is positive, instead of having mixed-mode arithmetic in the loop control. :-) > ....inbuf[index].... > } > } Otherwise I agree completely. I have a feeling that those who are used to thinking about computing as a series of operations on bits are much more likely to prefer unsigned, at least in C, just to get away from the standard madness which is C signed. :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: Chris Gray on 27 Jun 2010 19:34 Andy 'Krazy' Glew <ag-news(a)patten-glew.net> writes: > Note that the code you descrbe does NOT simply work with unsigneds in C, whereas it works with signed. > > I.e. you cannot simply say > > unsigned response_count; > response_count++; > assert( response_count > 0 ); The pattern we used is: responsesLeft := <count_of_nodes>; responseArrives: ASSERT(responsesLeft != 0); responsesLeft -= 1; > Agreed. It wouyld be nice to have the system tell you are trying to make an unsigned number negative. > Note, however, that the C standard defines this, saying that it is > modulo arithmetic. Or maybe they only define modulo for positive > numbers. Somebody'll tell me. In any case, C does not give you an > error if you try to make an unsigned negative, except in the simplest > cases. Right, so this has to be done in a variant of C, or some other language. > In general, specifying ranges for integers is a good idea. Remember > var a 32..63 ? I don't remember that syntax from anywhere. However, I had ranges in my "Draco" language. I found they were not very useful and only ever used them in one program, and they were clumsy there. Perhaps I was misusing them, but what I found was that I needed to break out of the range far too often. -- Chris Gray cg(a)GraySage.COM
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on 28 Jun 2010 03:44 Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote: > On 6/27/2010 9:51 AM, Robert Myers wrote: > > Terje Mathisen wrote: > >> Anton Ertl wrote: > > > >> > >>> But of course, all of this is outside the standardized subset of C. > >> > >> In my not so humble opinion, this is simply broken. > >> > > > > What this thread has demonstrated to me, yet again, is what a fatally > > flawed enterprise c is, and yet, I know that, without c or something > > like it, we would never have anything like Linux. > > I think that C was less flawed before the standardization process got a > hold of it. In this aspect, at least. I think it is more a problem of some compiler writers choosing to eliminate the difference between implementation defined and undefined. Nothing other than common sense prevented something similar before the C standard. -- Mvh./Regards, Niels J�rgen Kruse, Vanl�se, Denmark
From: Jean-Marc Bourguet on 28 Jun 2010 05:10
nospam(a)ab-katrinedal.dk (Niels J�rgen Kruse) writes: > Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote: > > > On 6/27/2010 9:51 AM, Robert Myers wrote: > > > Terje Mathisen wrote: > > >> Anton Ertl wrote: > > > > > >> > > >>> But of course, all of this is outside the standardized subset of C. > > >> > > >> In my not so humble opinion, this is simply broken. > > >> > > > > > > What this thread has demonstrated to me, yet again, is what a fatally > > > flawed enterprise c is, and yet, I know that, without c or something > > > like it, we would never have anything like Linux. > > > > I think that C was less flawed before the standardization process got a > > hold of it. In this aspect, at least. > > I think it is more a problem of some compiler writers choosing to > eliminate the difference between implementation defined and undefined. Overflow for signed computation is undefined behavior, not implementation defined; it's even the exemple of undefined behavior given in the section defining "undefined behavior". > Nothing other than common sense prevented something similar before the C > standard. Common sense: nobody thinks lacking it, everybody think other are missing some. I think this is a case of different people wanting different things for C. The end result in gcc (options -fwrapv/-ftrapv allowing to ask for wrap around/trapping instead of letting it uses all the lattitude open by the standard) would be good if only -ftrapv worked reliably... It is more difficult to test if -fwrapv work -- on the one hand it is probably more tested than -ftrapv (it is implicit for Java according to the documentation), on the other hand the fact that -ftrapv doesn't isn't a confidence builder. Is there other compilers allowing to control this? Or at least documenting that they are using one or the other choice? Yours, -- Jean-Marc |