23 Apr
2002
23 Apr
'02
10:01 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 22, 2002 7:34 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
Yes, it does, which was my point. There are limits, though.
I just finished an interrupt handler before breakfast, so I guess it hasn't
been as long for me. Of course, it's in 805x assembler ...
It was thus said that the Great Richard Erlacher once
stated:
>
> so I meant that while you may have software that creates really pretty
decent
> code for one platform, that same source code may
not produce as good a
product
> on another, and, in fact, may produce pretty bad
code for yet another set
of
> hardware. There's plenty of evidence of
that, at least according to
people
with whom I
routinely interact.
Depends upon the compiler, and also what you are trying to do.
> I personally code in assembler for the MCU's I use and occasionally use a
> compiler if I have an environment where timing is not critical all the
time
> and where it's easier to use logic spelled
out in 'C' or Pascal. That
often
> means that interrupt code is written in assembler
while message generation
or
> communication code is produced by a compiler.
Portability is seldom an
issue
for me.
For embeded systems I don't think portability is an issue really. And
while I'm not sure if you work on embedded systems or not, if you are
writing interrupt code, then yes, I can see why you would use assembler for
that (heck, even the Linux kernel has the low level interrrupt routines in
assembler). Me, I haven't had need to write an interrrupt handler in oh,
maybe eight to ten years, but my code tends to be more of an application
level that may or may not run on different computers.
-spc (Have code that's moved from SGIs to Suns to IBMs to HPs to PCs
to Amigas to ... )