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: Nick Maclaren on 7 Apr 2008 09:14 In article <cNoKj.13308$h65.12966(a)newsfe2-gui.ntli.net>, "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: |> |> > "Adding a macro here and there" is precisely what I meant by doing it |> > wrong. And, no, endianness does not change the sizes of anything - but |> > genuinely portable code can handle size, endian and other differences. |> |> Changing endian does change structure size, this is exactly the kind of thing |> that catches the less experienced people :-) Just exactly HOW does reordering bits change the space they take or their alignment? Look, I know that systems that run different endianness often have different sizes and alignments, even on the same hardware, but it has damn-all to do with the endianness as such. |> > And the first rule of doing it right is to get all of that system- |> > dependent crud out the main code, and localise the translations into |> > and out of a common, portable, clean working format. I.e. precisely |> > the CONVERSE of C99. |> |> That's certainly possible but usually infeasible if you need efficiency (and it's |> way overkill if you need to do something simple anyway). You usually want to |> work using the host endian and only swap input/output data when absolutely |> required. C99 doesn't come into it, people were mapping C structures onto |> hardware and file formats since the early days of C. And it works if you know |> what you are doing... No, you don't - standard software engineering (including from long before that term was invented). This is not the group to explain why, but think of validity checking, tracing and so on. And my remark referred to the stdint.h controversy, which you may or may not know about. |> So explain how you would test multiple orthogonal choices that have complex |> interactions with each other without testing most of the cross product. See above. You can simplify an NxN problem by converting it into a Nx1 and a 1xN problem. Regards, Nick Maclaren.
From: Anton Ertl on 7 Apr 2008 09:40 "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: >Any non-trivial piece of C code will only work on one endian unless it >was specifically designed to work in both (having done that at various >levels I know how much work this really is). In my experience byte order is a relatively rare portability problem in the C code I write and maintain. Problems related to the C zoo of types and their varying sizes and size relations are much more frequent, even though I have experience with porting C between different platforms. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
From: Noob on 7 Apr 2008 10:25 Nick Maclaren wrote: > Look, I wrote code in the days when we had to handle word sizes > that weren't powers of two, systems that weren't twos' complement, and > so on. I can assure you that handling what you describe isn't even > tricky - IF it is done right! Do you have a tutorial publicly available somewhere? > And the first rule of doing it right is to get all of that system- > dependent crud out the main code, and localise the translations into > and out of a common, portable, clean working format. I.e. precisely > the CONVERSE of C99. I should stick with C90 then? or use a different language? Regards.
From: Wilco Dijkstra on 7 Apr 2008 10:39 "Nick Maclaren" <nmm1(a)cus.cam.ac.uk> wrote in message news:ftd6np$fhn$1(a)gemini.csx.cam.ac.uk... > > In article <cNoKj.13308$h65.12966(a)newsfe2-gui.ntli.net>, > "Wilco Dijkstra" <Wilco_dot_Dijkstra(a)ntlworld.com> writes: > |> > |> > "Adding a macro here and there" is precisely what I meant by doing it > |> > wrong. And, no, endianness does not change the sizes of anything - but > |> > genuinely portable code can handle size, endian and other differences. > |> > |> Changing endian does change structure size, this is exactly the kind of thing > |> that catches the less experienced people :-) > > Just exactly HOW does reordering bits change the space they take or > their alignment? Combine non-pure endian types with bitfields. It should be easy to work out an example (remember you thought it was trivial?). Alignment never changes. > No, you don't - standard software engineering (including from long before > that term was invented). This is not the group to explain why, but think > of validity checking, tracing and so on. And my remark referred to the > stdint.h controversy, which you may or may not know about. There isn't any stdint.h controversy. Everybody used fixed-width types like int32 long before stdin.h and continues to do so. It's basic software engineering as you say. The only thing that sometimes causes discussion are the redundant fast_xxx and least_xxx types, but few use them anyway. > |> So explain how you would test multiple orthogonal choices that have complex > |> interactions with each other without testing most of the cross product. > > See above. You can simplify an NxN problem by converting it into a > Nx1 and a 1xN problem. That is only possible if the choices are truly independent of each other - which they aren't in this case. Another well known example is trying to represent N languages and M target architectures using a single intermediate language. Unfortunately it doesn't work like that in the real world... Wilco
From: Nick Maclaren on 7 Apr 2008 10:57
In article <47fa2edf$0$26675$426a74cc(a)news.free.fr>, Noob <root(a)localhost> writes: |> |> > Look, I wrote code in the days when we had to handle word sizes |> > that weren't powers of two, systems that weren't twos' complement, and |> > so on. I can assure you that handling what you describe isn't even |> > tricky - IF it is done right! |> |> Do you have a tutorial publicly available somewhere? I am afraid not. The key is 'localisation' (also known as 'encapsulation'). You write modules/functions/whatever that hand external interfaces, and they check the data for validity as it goes in and out, and convert to and from your internal formats. Your internal formats are generic (see below), and you don't rely on anything system-specific like endianness or overflow handling in them. |> > And the first rule of doing it right is to get all of that system- |> > dependent crud out the main code, and localise the translations into |> > and out of a common, portable, clean working format. I.e. precisely |> > the CONVERSE of C99. |> |> I should stick with C90 then? or use a different language? Yes :-) More seriously, DON'T use those horrible fixed-width integers except in your interface code - and they don't help much with that, because they don't define the endianness or bounds behaviour. What most of your code should use is types that are bound to properties, such as: The ability to address all parts of a single object. The ability to address all of virtual memory. The ability to address all of any direct-access file. The ability to hold the value of any integer type (this was 'long' in C90, and was broken by C99). Regards, Nick Maclaren. |