Intel Atom vs ARM
|
Prev: NTP: (Was: Re: performance of hardware dynamic scheduling)
Next: A race-condition in a SUN paper by Detlefs on reference counting...
From: Andrew Reilly on 8 Apr 2008 19:46 On Tue, 08 Apr 2008 10:38:20 +0000, Wilco Dijkstra wrote: > This code is 100% portable to any compiler that implements the C99 > standard. In fact even most non-C99 compilers can compile this code > flawlessly - long long was a defacto standard well before C99. Yeah, but implementing it does not require anything in particular with regard to size or packing. I would expect that any sane compiler going for speed (i.e., in the absence of necessarily non-portable packing pragmas) would just ignore the bitfield designations altogether, and treat it as a regular struct of full words. I've never had the desire or occasion to use bitfields myself. They're part of the C standard that I would be extremely happy to see dropped in the future. Any sane bit packing happens with shifts and logical or aritmetic operations, IMO. Cheers, -- Andrew
From: Duane Rettig on 8 Apr 2008 22:30 "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: > "Duane Rettig" <duane(a)franz.com> wrote in message news:o0skxwo08q.fsf(a)gemini.franz.com... >> "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: >> >>> "Duane Rettig" <duane(a)franz.com> wrote in message news:o0bq4ltf71.fsf(a)gemini.franz.com... >>>> "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: >>>> >>>>> "Duane Rettig" <duane(a)franz.com> wrote in message news:o0iqyttzes.fsf(a)gemini.franz.com... >>>>>> "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: >>> >>>>> struct X { >>>>> int x : 16; >>>>> long long y : 33; >>>>> long long z : 15; >>>>> } >>>> >>>> Ah, so you're giving me non-portable code to prove non-portability. I >>>> see. >>> >>> That shows how little you know about writing portable code and the C standard... >> >> Tsk. Such strong words. > > Well, I did prove that endianness has an effect on structure size just like > alignment does, so dismissing it by claiming it is non-portable is disingenious. > >>> This code is 100% portable to any compiler that implements the C99 standard. >>> In fact even most non-C99 compilers can compile this code flawlessly - long long >>> was a defacto standard well before C99. >> >> Compiling code flawlessly doesn't mean compiling code portably. You >> have abdicated any size or endianness criteria. > > If it compiles and works flawlessly (with little effort) then it was portable. > The fact that structures may have different sizes when alignment or endian > is different is not a proof of non-portability - by definition code is portable > if such differences either don't affect its correctness or have been avoided > by design. > >> But in this day and >> age it is important for languages to talk to each other, and they must >> do so on nonhomogenous machines and operating systems. The >> requirements for portability can extend beyond one language >> specification, even C's. >> >> No, we simply disagree on the definition of portability. > > No, you're confusing portability with binary compatibility. No, it is you who are confused because you refuse to confront the fact that others who have been responding to you have a different definition than you do. The word "portable" is a generic term, which has many different meanings, and you are obviously using the term as if to mean "source portable". But as I said above, and as you should have been able to gather from others who have corrected you, you cannot use the unadorned word "portable" and expect others to agree with you: Nick originally used the term "genuinely portable" to make obvious the fact that he was talking about something more than source portability. He further explained himself by using the phrase "localise the translations into and out of a common, portable, clean working format", clearly refering to binary portability, which you are insisting here on calling binary compatibility. A few articles later, someone else asked the question (without a question mark) "Doesn't the recommendation to avoid bit fields if you are interested in the portable data layout appear in every C book in existence."; another obvious reference to binary portability. I also used the phrase "whether the abstraction at the source level can be made portable." Obviously I was talking about source in the first part, but the subtlety would have been missed by anyone hard set on his own terminology as to the fact that the second part: "... can be made portable." was indeed talking about _binary_ portability, not source portability - obviously non-portability of code that is otherwise be portable at the source level _must_ be referring to something _other_ than source portability. This was the same article in which I joked that you were proving non-portability using non-portable code (once again, in the sense that the code is documented not to generated portable layouts at the binary level). If you want to continue this conversation, first come to grips with the terminology that others who have been discussing with you have been using. -- Duane Rettig duane(a)franz.com Franz Inc. http://www.franz.com/ 555 12th St., Suite 1450 http://www.555citycenter.com/ Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Wilco Dijkstra on 9 Apr 2008 07:38 "Andrew Reilly" <andrew-newspost(a)areilly.bpc-users.org> wrote in message news:662eevF2ihoseU1(a)mid.individual.net... > On Tue, 08 Apr 2008 10:38:20 +0000, Wilco Dijkstra wrote: > >> This code is 100% portable to any compiler that implements the C99 >> standard. In fact even most non-C99 compilers can compile this code >> flawlessly - long long was a defacto standard well before C99. > > Yeah, but implementing it does not require anything in particular with > regard to size or packing. I would expect that any sane compiler going > for speed (i.e., in the absence of necessarily non-portable packing > pragmas) would just ignore the bitfield designations altogether, and > treat it as a regular struct of full words. I'm not aware of any compiler doing this, but it would only be possible if it could proof that is correct (which is hard). Bitfields may be used to match a particular file format, or to reduce memory usage. Additionally, when you write a value into a bitfield, it is truncated to the bitsize of the field, so you'd need to prove no truncation ever happens, or you can't reduce the overhead. > I've never had the desire or occasion to use bitfields myself. They're > part of the C standard that I would be extremely happy to see dropped in > the future. Any sane bit packing happens with shifts and logical or > aritmetic operations, IMO. You can do bit packing by hand of course, but using bitfields gives the same effect, and with less effort. Bitfields are often necessary when you have various booleans in a structure, and many thousands of instances of that structure. The reduced memory footprint often more than compensates for the overhead of a bitfield access (which for booleans it is pretty minimal). It's definitely true bitfields are grossly underspecified by the various C/C++ standards, but this is easily fixable. I designed a sane bitfield layout algorithm for the ARM ABI, which works for all types, sizes, alignments etc. Even details such as oversized and zero-sized bitfields are specified in a way that makes sense. It's being adopted by a growing number of compilers. Wilco
From: Ken Hagan on 9 Apr 2008 08:03 On Tue, 08 Apr 2008 23:55:12 +0100, Wilco Dijkstra <Wilco_dot_Dijkstra(a)ntlworld.com> wrote: > When using C types you have to be careful - few know I16LP32 is a valid > model, so using 'int' without care often results in non-portable code. I16LP32 looks like "large model" for DOS or Win16. Are there realy so few of us left, so soon?
From: Andrew Reilly on 9 Apr 2008 09:41
On Wed, 09 Apr 2008 13:03:33 +0100, Ken Hagan wrote: > On Tue, 08 Apr 2008 23:55:12 +0100, Wilco Dijkstra > <Wilco_dot_Dijkstra(a)ntlworld.com> wrote: > >> When using C types you have to be careful - few know I16LP32 is a valid >> model, so using 'int' without care often results in non-portable code. > > I16LP32 looks like "large model" for DOS or Win16. Are there realy so > few of us left, so soon? Large model was kind of funky, though, with the P32 really being a redundant packing of P20. I think that the poster child for I16LP32 was probably 68000 and 68010 code, before the 68020 made it a fully fledged 32-bit processor. Any other takers? The NS16032 springs to mind, but I think that it was always really an ILP32 machine, like the Vax. Never got to code for one seriously, though. Other machines with I16 that I can think of tended to have P16 too, even if there was odd paging or segmentation going on as well. Cheers, -- Andrew |