On 1 Aug 2007 at 20:56, dwight elvey wrote:
I'm not sure why you'd say that. It is a
simple programming language
but is quite remote from most any assembly language I've worked
with. The only higher level languages that I've worked with that
I could say were close to assembly were Forth and LISP. That is
only because there were machines made that were dedicated to
that particular lanuage.
C doesn't fit well onto any of the processors that I've seen lately.
It is always sub-optimal.
I code a lot of C, mostly for portability between systems. I don't
like a lot of aspects, but it's "good enough" for most things--and
there is the facility for coding inline assembly in many compilers.
What's been depressing through the entire period of microcomputers is
the lack of a really good assembler. Very many lack a literal
constant facility, e.g. LEA EDX,="This is a string literal". Few
assemblers implement data types in their macro language;; in
particular, arrays of objects usually have to be synthesized
lexically; there is usually no facility for remote assembly
(specifying code to be stored and assembled in another location; very
handy with macros). The list goes on. The odd thing is that most of
these facilities were present in 60's era mainframe assemblers, where
those facilities really did make things easier.
I recall doing a command processor for an operator's console that
featured auto command completion. A good assembler allowed me to
specify the text value and format of each command and a good macro
language compiled the list into a tree structure.
C's preprocessor is very anemic. An example of a good preprocessor
is that of PL/I, which almost duplicates most of the imperatives in
the language for use at preprocessor time. In C++, some individuals
take a perverse delight in showing that all manner of computation can
be done using the template facility, but the same computations using
the PL/I preprocessor would have been simple.
Enough ranting. You work with what you have.
Cheers,
Chuck