| Darren New 2007-06-29, 4:20 am |
| Melissa Schrumpf wrote:
>
> Strictly-speaking, are they, or have the embedded-target C compilers
> just been optimized for so long that they just happen to be the best
> tools available?
I've worked with several mainframes that were unable to support C. They
were some of the most powerful mainframes of their time. Try to sell any
CPU nowadays that can't support C and see what happens. I'm not talking
about just embedded stuff - to me, "microcomputer" includes anything not
designed for I/O over compute speed. :-)
(Of course you can support C on any machine by either writing an
interpreter or letting undefined things really crash the machine. Not
very efficient tho. Plus, of course, there are *some* really small
"postage-stamp" style machines that (say) only run PIC-Basic or some
such, but they really aren't too general purpose either.)
>
> But it's not C itself that runs on the processor, it's the machine code
> to which it is ultimately converted. Isn't it more a matter that the
> optimal language for any system would be that which most closely
> reflects the underlying architecture, so that compiler abstractions need
> not be overly lossy?
Well, take for example a Burroughs B-series machine. Each memory
location was tagged with the type of data stored there. You couldn't
take an integer and store it into a pointer variable. You couldn't have
a union of a double and a long. You couldn't implement something like
printf() that took variable types of arguments in different calls. The
CPU "add" instruction just had the addresses of the operands to add, and
took the types of the data stored at those addresses to figure out
whether to add floats, add integers, etc. You could run C on such a
machine only by writing an interpreter for it. OTOH, Pascal and Algol
ran fine.
C makes some assumptions about your architecture that, if your
architecture doesn't support it, complex C programs won't run. That ints
and pointers are interchangable, that there's an address type that can
point to any address (i.e., that it's possible to have a void*), that
it's possible to take the address of a function and branch to it, that
all your data is in the same address space at the same time, and so on.
I've used embedded systems where it wasn't possible to take the address
of a function, for example, because each function was in its own address
space due to address paging translation sorts of things. Or a machine
that has a block of memory for integers, a block of memory for floats,
etc. That would work fine for BASIC and APL (and maybe old FORTRANs?),
and C just plain wouldn't run.
You don't see those sorts of architectures any more. Nor do you often
see architectures targeted at other languages, like having the
COBOL-specific opcodes lots of mainframes used to have. Popular
languages influence CPU design at least to that extent.
--
Darren New / San Diego, CA, USA (PST)
I bet exercise equipment would be a lot more
expensive if we had evolved from starfish.
|