The Cyber-Spy.Com Usenet Archive Feeds Directly
From The Open And Publicly Available Newsgroup
This Group And Thousands Of Others Are Available
On Most IS NNTP News Servers On Port 119.
Cyber-Spy.Com Is NOT Responsible For Any Topic,
Opinions Or Content Posted To This Or Any Other
Newsgroup. This Web Archive Of The Newsgroup And
Posts Are For Informational Purposes Only.
From: "Frank Bemelman"
References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
Subject: Re: To C or not to C
Date: Sun, 5 Jan 2003 13:31:29 +0100
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
Organization: EuroNet Internet
NNTP-Posting-Date: 05 Jan 2003 12:31:46 GMT
"Jonathan Kirwan" schreef in bericht
> On Sun, 5 Jan 2003 01:42:26 +0100, "Frank Bemelman"
> >Okay, I'll keep scratching my head in the meantime ;)
> For example, rather than:
> #define MAXBUF (128)
> in a .H file, I might instead use:
> const MAXBUF = 128;
> in a .C configuration file which I could then compile into an
> .OBJ or .O. The linker would have access to this symbolic value
> and would link it appropriately with any extern references to
> it, substituting the values at link time.
> Without this mechanism, the C compiler must recompile each and
> every .C file which includes the .H, rather than recompiling
> only the configuration constants file and then linking. For
> large projects, this can be kind of nice.
Okay, but this more a convenience issue.
> But there are other values to this. For example, being able to
> specify absolute addresses for memory mapped peripheral
> registers and so on. Some of the embedded C compilers actually
> provide pre-compiled .OBJ or .O files which include these
> predefined symbolics in them for convenience and provide
> appropriate .H files for inclusion. But it isn't possible to
> produce those .OBJ files (or .LIB) without the assembler being
> involved. C just doesn't have a syntax to specify the semantics
> for it.
Well, some C compilers offer extensions allowing you to write
BYTE lcd_command @ 0xC000;
... but I'm the first to admit I had to write a small ASM module
to take care of such things. But I don't call that writing in
> Generating equal times in the 'then' and 'else' clauses of an
> 'if'. I recently encountered a situation, in doing bus
> arbitration between a variable number of asynchronous devices
> sharing it, where the timing of each address bit during the
> arbitration phase (much like the APIC bus on the Intel P II
> cpus) depended on some constant factors PLUS two times the
> variability in the bit timing. Since this was an active low,
> high impedance high type of line sharing, the microcontroller
> had to use two different mechanisms for driving a '0' and a '1'.
> This meant that I couldn't just mask the bit and drive it to the
> latch. I had to use an 'if' statement and do different things
> depending on whether the bit was a 0 or 1. However, if the
> 'then' and 'else' clauses had different timing, I'd have to
> double that variability and add it into the total bit time and
> this could greatly slow down the resolution process.
This is a speed issue. You want maximum speed, or control over
> C simply doesn't provide a syntax to allow the programmer to
> specify to the compiler that this is a desired outcome. Not
> even nice #pragma's for this, for example. No amount of
> screwing around with the C code would help here. It's plain and
> simple, not in the C card deck.
That's true. OTH if I needed to balance a 'then-else' I'd may
try if the compiler understood NOP(); or else I might try
something like dummy++;
> Co-routines. It would take a while to properly elaborate this
> one. A quick example in pig-C might get the point across more
> quickly, though:
> the case of the Primes() call, for example, the full set of
> primes do not need to be passed back nor fully computed before a
> yield takes place. There is no equivalent in C. But this is
> actually quite easy in assembly (and some other higher level
Lost you here completely, sorry ;)
> Assembly is quite a bit more flexible than C. The difficulty is
> that one needs to have a broader set of mental models in order
> to take advantage of that flexibility.
Well, I lack that broader set of mental models. Your examples are
good, and obviously you are using 'assembly' at an entiry different
level than (I assume) most are doing. I my case I'm often more
concentrating on the application itself, not some deep buried gearbox.
I have the impression that you are more involved with the very
complicated gearboxes ;)
> Anyway, I just wanted to point out that those limiting their C
> vs assembly arguments to "speed" or "space", being unable to see
> any other reasons, are in fact myopic and color blind in their
> views. There is a bigger, more colorful world out there, most
> especially in embedded work. And C vs assembly for embedded use
> doesn't just boil down to speed and space and development time.
> I admit it often does so, but not always. And it's the times
> when it doesn't boil down that way, that things are really more
ASM is harder to write, and when used at a higher level I fear
that it does not result in the best possible application, or
perhaps a rather spartanic application. 'Embedded' suggests a
small area, but in fact it is a very wide area with many different
diciplines. Trying to deny that is a form of colorblindness too ;)
(remove 'x' & .invalid when sending email)
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup