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: Martin Thompson on 8 Apr 2008 08:18 Paul Gotch <paulg(a)at-cantab-dot.net> writes: > No because the BOMs for TVs are incredibly cost sensitive they will not use > a chip that costs $6, it would have to be $1 and TVs have no use for x86 > compatability as no consumer electronics manufacturer in their right mind is > going to ship a TV which you can run user programs on, I thought that, but my recent TV purchase (an inexpensive 19" LCD TV) has an RS232 port on the back (and documentation on how to use it!), and came with a set of printed schematics! Cheers, Martin
From: Jon Harrop on 8 Apr 2008 10:43 Martin Thompson wrote: > Paul Gotch <paulg(a)at-cantab-dot.net> writes: >> No because the BOMs for TVs are incredibly cost sensitive they will not >> use a chip that costs $6, it would have to be $1 and TVs have no use for >> x86 compatability as no consumer electronics manufacturer in their right >> mind is going to ship a TV which you can run user programs on, > > I thought that, but my recent TV purchase (an inexpensive 19" LCD TV) has > an RS232 port on the back (and documentation on how to use it!), and came > with a set of printed schematics! Awesome. :-) -- Dr Jon D Harrop, Flying Frog Consultancy http://www.ffconsultancy.com/products/?u
From: Duane Rettig on 8 Apr 2008 11:05 "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. > 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. 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. >> Well of course every type has a size. That's also not at issue. The >> question is if the size matters, and whether the abstraction at the >> source level can be made portable. For example, we use a typedef >> called "nat", which is meant to be the natural word size of the >> program being run. > > OK, so you do exactly the same as everybody else: using typedefs for types rather > than using the standard ones. So I think we all agree the C builtin types are useless > and non-portable. Hyperbole again: We do not _all_ agree. I make great use of C types in many situations, and cover up the implementations that are not quite so portable for our requirements. I make no use of bit fields, which are not portably _implemented_ (i.e. in their layout). > The models you mentioned have the same sizes for most types > apart from pointers (and sometimes long), so it's hard to argue they > are evil. Why are you trying to put words into my mouth? I've never said anything about them being evil. You are in fact agreeing with me, that in fact I use most of the types portably, and only have to cover up types from the models that don't match our requirements. > You may > not rely on their exact width but you still require them to be a specific minimum width. No, I do rely on their exact width, so my program doesn't have to. >>> So you add some more specific intermediate instructions and semantics. Do this >>> for several languages and targets, and you either end up with a huge intermediate >>> language >> >> but "huge" is so relative... >> >>>> or complex intermediate instructions whose semantics varies with the context. >> >> or if you spend the time to refactor the intermediate language, you >> start refining it to the point where it is able to take on more >> targets with less added complexity. > > It's a nice ideal indeed, but has anyone ever succeeded in doing it? You can spend > a lot of time on refactoring, but there will always be languages that still don't fit in... We haven't had a problem with it. 20 years ago we did some refactoring when I did a port of our product to the Cray X-MP and Y-MP series (it was already portable wrt endianness). Later we did many of the more traditional 64-bit ports, each one added required almost no refactoring, and only needed some tweaking that could be considered simple bug fixes. We have an automatic "foreign" interface to C calling conventions, so our language interfaces quite effortlessly to C and languages which use C calling conentions. (but we do tend to stay away from bit fields :-) >>> The current compiler I'm working on supports 3 different exception models in the >>> intermediate language, and that's just 3 languages so far... To make matters worse, >>> each target encodes exception tables different enough that very little can be shared. >> >> Perhaps you're just not abstracting your intermediate model deeply enough. > > It has been abstracted as much as feasible. The problem is the semantics of various > exception models are so different you can't find a common high-level abstraction that > supports all. Of course at the lowest level you can represent exceptions as special > control flow edges in a CFG, but at that point you've lost most high-level info - and > thus the ability to optimise. Your program; your choices. You should take the responsibility, though, for not being able to find the common abstraction (i.e. instead of saying "... models are so different you can't ..." you should be saying "... models are so different I can't ...", though I have a feeling that the real truth would be closer to "... models are so different that I don't see any benefit in trying to ...", which is, by the way, a perfectly fine design tradeoff. -- 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: YANSWBVCG on 8 Apr 2008 14:20 Jon Harrop <jon(a)ffconsultancy.com> wrote: > Martin Thompson wrote: >> Paul Gotch <paulg(a)at-cantab-dot.net> writes: >>> No because the BOMs for TVs are incredibly cost sensitive they will not >>> use a chip that costs $6, it would have to be $1 and TVs have no use for >>> x86 compatability as no consumer electronics manufacturer in their right >>> mind is going to ship a TV which you can run user programs on, >> >> I thought that, but my recent TV purchase (an inexpensive 19" LCD TV) has >> an RS232 port on the back (and documentation on how to use it!), and came >> with a set of printed schematics! > > Awesome. :-) What commands can you give the LCD via the rs-232 port?
From: Wilco Dijkstra on 8 Apr 2008 18:55
"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. > I make great use of C types > in many situations, and cover up the implementations that are not > quite so portable for our requirements. I make no use of bit fields, > which are not portably _implemented_ (i.e. in their layout). 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. Structure layout and alignment is not usually binary compatible between different C implementations (unless they adhere to a common ABI). However this doesn't stop you from achieving binary compatibility in a portably way. For example you can control the size and alignment of structures - even if they include bitfields - using standard C. >> It's a nice ideal indeed, but has anyone ever succeeded in doing it? You can spend >> a lot of time on refactoring, but there will always be languages that still don't fit in... > > We haven't had a problem with it. How many different languages and targets do you support in your intermediate language? It's usually easy to do a few languages with many targets or many languages on a few targets, but things get hard when you have many of both... > Your program; your choices. You should take the responsibility, > though, for not being able to find the common abstraction > (i.e. instead of saying "... models are so different you can't ..." > you should be saying "... models are so different I can't ...", though > I have a feeling that the real truth would be closer to "... models > are so different that I don't see any benefit in trying to ...", which > is, by the way, a perfectly fine design tradeoff. Exactly. Assuming it is possible to find a better abstraction, you can abstract and refactor everything to perfection, and yet risk not being able to support the next language that becomes fashionable... Wilco |