Re: CC to small CPU still doesn't work?

albaugh@agames.com (Mike Albaugh)
9 Nov 1999 01:42:33 -0500

          From comp.compilers

Related articles
CC to small CPU still doesn't work? ppaatt@aol.com (1999-11-05)
Re: CC to small CPU still doesn't work? raugfer@uol.com.br (Rodrigo Augusto B. Ferreira) (1999-11-09)
Re: CC to small CPU still doesn't work? dhansen@btree.com (1999-11-09)
Re: CC to small CPU still doesn't work? albaugh@agames.com (1999-11-09)
Re: CC to small CPU still doesn't work? htak@eskimo.com (1999-11-09)
| List of all articles for this month |
From: albaugh@agames.com (Mike Albaugh)
Newsgroups: comp.compilers
Date: 9 Nov 1999 01:42:33 -0500
Organization: Atari Games Corporation
References: 99-11-035
Keywords: C, architecture

PPAATT (ppaatt@aol.com) wrote:
: Am I correct to think the world still lacks a C compiler that can
: effectively target a CPU existing on just x100 bytes of Ram?


There are several commercial "C" compilers targetting some pretty
small micros (PIC et al) I do not have direct experience with any of
them, so I can't comment on that part.


: I'm not interested in rewriting All the machine code (except that I am
: interested in competent disassembly, another unmet need), but I do
: wish I could use the anonymous balanced {} braces of C to express the
: control flow of the new code I write, rather than having to use labels
: and goto. Structured control would alone be a step forward.


Back when we wrote a lot of assembly, we used to use a set of
macros that implmented something like Wirth's PL/360. that is, instead
of:


TST.L D0
BEQ .l0
....
.l0


we wrote:


IFNE D0
....
ENDIF
(plus BEGIN .. WHILE ... REPEAT et al, and yes, they could be nested)


This worked remarkably well for the 8-bitters we used, which had an
assembler derived from DEC Macro-11. When we hit the 68000, the
quirkiness of the instruction-set, and the weakness of the available
macro-assemblers, made this approach less palatable. Add decently
competent C compilers, and we just made the switch. But it sounds like
you are more in our "early" position.


: Having a compiler that choose competently from among the bit/byte
: short/long


That would also be possible, given a decent macro-assembler
and/or one that automagically carried type information. These are
rare, today, but "You could wrote one" :-)


: maths/jump instructions would be nice too, of course.


Not sure what you mean by that.


: The last documented tool survey where I work occurred before the
: Internet exploded. So I thought I'd ask. Pointers, anyone?


It is important to note that EDSAC's "Initial Orders" implemented
something a great deal more like Forth assembler (or the above approach)
than like "modern" assemblers. In this respect, we took a pretty
fair-sized step backward, at some point... :-)


Mike
| albaugh@agames.com, speaking only for myself


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.