Re: Microcontroller ... which one ??

From: Ken Smith (kensmith_at_green.rahul.net)
Date: 11/28/04 

Date: Sun, 28 Nov 2004 20:25:52 +0000 (UTC)

In article <pan.2004.11.28.19.29.22.170993@att.bizzzz>,
keith <krw@att.bizzzz> wrote:
>
>Since it's being cross-posted to a new group, I'll trim closely...
>
>On Sun, 28 Nov 2004 17:16:07 +0000, Ken Smith wrote:
>
>> The discussion is about the portability of C. We are not talking about
>> just general purpose computers. DSPs and micro-controllers are at issue.
>
>Also ignoring Harvard architectures (like the 8051) and special function
>registers (which are obviously hardware dependant).

Ok, I'll include that limitation to the scope of the argument. Things
like the transputer are alos off the table. I think they are too weird to
make a C compiler for. We can limit the discussion to only those machines
for which a reasonable C compiler can be written.

>
>> In article <pan.2004.11.28.05.03.10.61137@att.bizzzz>, keith
>> <krw@att.bizzzz> wrote:
>>>On Sat, 27 Nov 2004 22:07:04 +0000, Ken Smith wrote:
>>>
>>>> In article <pan.2004.11.27.19.03.02.32327@att.bizzzz>, keith
>>>> <krw@att.bizzzz> wrote:
>>>> [...]
>>>>>I think if you make that statement over on comp.arch you'll get a lot
>>>>>of argument. AIUI (I'm just a hardware type, can't spell 'C') it is
>>>>>possible to write portable 'C', but it's not trivial.
>>>>
>>>> For simple programs it may be possible to do but you'd better watch it
>>>> if you use strings. In some cases it is best to just store one
>>>> character per integer.
>>>
>>>Are you man enough to take it to C.A? Trust me, you'll get chewed up
>>>and spit out by people who do just this for a living.
>>
>> Consider it taken there if I did the headers right.
>
>No, not C.A.C. It might work, but I meant C.A. I've seen exactly this
>argument before in C.A. I've never followed C.A., since I'm a hardware
>type. A Google NG search might keep from upsetting the natives too. ;-)

If we don't get a reaction, one us will have to change the groups line. I
did not because it is way too early to expect any reaction.

>>
>>
>>>> All more complex types such as structures and unions are composed of
>>>> the simple types. They also can't be passed to subroutines.
>>>
>>>Of course not, pointers to structures are. But the basic types are
>>>defined in the language specification too. Because *you* choose to
>>>bastardize them, you shoot yourself in the foot. 'C' is really good at
>>>letting the incompetent do that (which is why I don't do 'C').
>>
>> "the basic" types means the same as the "simple types". Or are you
>> suggesting that some arrays or structures are now part of the language
>> definition?
>
>I'm only reporting what the language experts say. They claim to do
>portable C reliably, every time.

But ... but ... are they porting to microcontrollers etc. In the general
purpose computer world things can be quite different. Companies like
Prime and DEC no longer exist so there aren't many non-byte oriented
general purpose computers any more.

>> I maintain that "complex types" end up being machine dependant because
>> they are defined from the "simple types". I have also said that "long
>> int", "short int", "int", "float" and all pointers are machine dependant
>> because thir meaning changes for non-byte oriented processors. Keith
>> (the other poster) asserted that "short int" means 16 bits and that
>> "long int" means 32 bits.
>
>I never explicitly stated anything of the kind. I states simply that
>portable C coding was possible without out polluting the code with
>massive IFDEFs and such.

I thought you did. Maybe I confused you with some other poster. Sorry if
I did.

>
>>>Tell it to the real programmers over on comp.arch, if you dare. I'll
>>>lurk and watch you burn too. I've seen these flame-fests before. The
>>>incompetents always run away with flaming tails.
>>
>> I assume you mean "comp.arch.c"
>
>No, I meant "comp.arch", where much of this stuff has been hashed out
>ad-nausium. I've never followed comp.arch.c, so I know none of the
>regulars.

Well we will see if this get more hash or just ignored. Fasten your seat
belt, it may be a bumpy ride. 

-- 
--
kensmith@rahul.net   forging knowledge
Quantcast