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: already5chosen on 9 Apr 2008 11:56 On Apr 9, 1:38 pm, "Wilco Dijkstra" <Wilco_dot_Dijks...(a)ntlworld.com> wrote: > Bitfields may be used to match a particular file format, or to reduce memory usage. In non-portable code, that is. In the portable code - only for later. >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. Even for loads a single AND is cheaper than shift+AND. For stores the difference is much bigger. > > It's definitely true bitfields are grossly underspecified by the various C/C++ > standards, but this is easily fixable. They specified just fine. IMHO. >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. > Which is fine as long as the code is explicitly non-portable. Which, BTW, too is fine most of the time (Nick is going to disagree). > Wilco
From: Nick Maclaren on 9 Apr 2008 12:39 In article <71d38e5e-fc00-4579-bc19-742decd62281(a)p25g2000pri.googlegroups.com>, already5chosen(a)yahoo.com writes: |> On Apr 9, 1:38 pm, "Wilco Dijkstra" <Wilco_dot_Dijks...(a)ntlworld.com> |> wrote: |> |> >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. |> |> Which is fine as long as the code is explicitly non-portable. Which, |> BTW, too is fine most of the time (Nick is going to disagree). True. IBM thought as you did, once - now they agree with me :-) Regards, Nick Maclaren.
From: Greg Lindahl on 9 Apr 2008 13:33 In article <663vd4F2hhc3iU1(a)mid.individual.net>, Andrew Reilly <andrew-newspost(a)areilly.bpc-users.org> wrote: >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. All the 68000 systems I used were ILP32. The 68000 is a full-fledged 32-bit processor in the John Mashey universe; if you're obsessing about the width of the external memory interface, later 680x0 processors had a variable width. -- g
From: Andrew Reilly on 9 Apr 2008 19:24 On Wed, 09 Apr 2008 10:33:02 -0700, Greg Lindahl wrote: > In article <663vd4F2hhc3iU1(a)mid.individual.net>, Andrew Reilly > <andrew-newspost(a)areilly.bpc-users.org> wrote: > >>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. > > All the 68000 systems I used were ILP32. The 68000 is a full-fledged > 32-bit processor in the John Mashey universe; if you're obsessing about > the width of the external memory interface, later 680x0 processors had a > variable width. I think that it depended which system/environment you were using. I agree that architecturally it was clearly always a 32-bit processor, but I have a vague memory that there were some systems where the system C compiler had 16-bit int anyway. I didn't use any of them myself. Maybe Atari PCs running GEM? Maybe something that graduated from 6809 under OS/9 to 68000 and wanted some more compatability? I can well imagine that the demo scene assembly coders of the time would have used the 68k as a mostly-16-bit machine on the strength of minimising cycle counts. I know that I did. With no caches, memory width really does have a strong affect on these sorts of perception. The 68k variant of GCC has the -mshort flag, which makes int a 16-bit type. That's presumably there for a reason, probably compatability with something. Or performance. I've just found a web page with a 1987- vintage listing of Dhrystone results, which shows about a 50% advantage for 68000 systems when compiled with 16-bit int types, so clearly it was done (Manx and Lattice C compilers could apparently also select int size from the command line.) Aside from that vague memory, I can't think of any I16LP32 systems. Maybe some sort of extended addressing PDP-11 or Z8000? Cheers, -- Andrew
From: Terje Mathisen on 10 Apr 2008 02:09
Wilco Dijkstra wrote: > "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, Matching/mapping a file format against a C bitfield is non-portable. > 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. Rather the opposite: Truncating is only needed when storing, and at that point it is very cheap, a single AND against a fixed immediate value. This AND is normally needed for all stores into a bitfield anyway, to make sure that the compiler isn't clobbering the next field. What you save is the shift on both load & store, along with the mask operations during load and the OR to merge for stores. I.e. approximately 2-3 times faster than bitfields for L1 cached data. >> 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). One of my first commercial programs used bitfields to store a database of serial numbers, to be able to answer a single YES/NO question very quickly. It was _very_ obvious to me at the time (~1985) that I would do this by doing all packing/unpacking by hand: The database consisted of disk blocks of exactly 4096 bytes, of which the first 96 bytes were the header (containing some maintenance/verification info, like the number of set bits) and the remainder contained exactly 32000 bit records. The result was a program that would handle/verify 10K semi-random updates against a database of 10M records, in a single second, while running on a 6 MHz 286. > > 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. _That_ sounds like a _very_ good idea! Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching" |