Re: How Tcl speaks for itself and how Tcl is not spoken for... (Drifting off-topic)

Melissa Schrumpf wrote:
Plus, many of those microcomputers are designed to be programmed in a C-like language.

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 since C might run poorly on such an architecture, they never really
make it to wide-spread market adoption.

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.
.

Relevant Pages

  • Re: Architectural support for programming languages
    ... microarchitectural support in processors for operating systems to make ... The language used will match the programs, ... were adding architectural features to take their share of new market ... and run them under and OS written in C and on architecture with all ...
    (comp.arch)
  • Re: various objects in my VB6 project - Calling IUnknown
    ... legacy support for EXEs is an order of scale beyond ... "Language Stability" enjoyably employs structure. ... But I'm not black and white on the matter of migration changes. ...
    (microsoft.public.vb.general.discussion)
  • RE: cannot import data manually on sql server 2005 because of collatio
    ... Your original collation of your SQL Server 2000 database is a Windows ... and this requires that the related language and locale must be ... Options, click on Languages tab, in Supplemental language support box, ...
    (microsoft.public.sqlserver.dts)
  • Re: how is Haskell not robust?
    ... Haskell has not reached critical mass. ... have a thousand packages but still poor support for mainstream package ... If anyone would make money with the language or a compiler ...
    (comp.lang.functional)
  • Re: Why should I eschew prototype.js?
    ... Microsoft drives this market, whether people admit it or not. ... out next week and proclaimed "The only markup language we will support ... Furthermore, if any other attributes are present, IE will ignore the script block. ...
    (comp.lang.javascript)