10 Oct
2003
10 Oct
'03
9:14 a.m.
I am looking for full source code for a *VERY* tiny C compiler written in
any common assembly language. I'm much more concerned with size of the
compiler than functionality/features. Can anyone suggest one or know where
the source might by laying around? I thought I had heard ages ago about some
microcomputer C compilers being well under 32K.
As to how this relates to classiccmp... well.. *blush* I'm actually thinking
of porting C to the HP2100. The whole thing has to fit in 32K of ram,
including drivers, etc. Not sure what OS it will be placed on, perhaps
HP-IPL/OS. Might make a simple native OS for it or might even make it
standalone, not sure yet.
Did I recently post about being overcomitted? heh
Jay
---
[This E-mail scanned for viruses by Declude Virus]
10 Oct
10 Oct
9:56 a.m.
On Fri, 10 Oct 2003, Jay West wrote:
I am looking for full source code for a *VERY* tiny C
compiler written in
any common assembly language. I'm much more concerned with size of the
compiler than functionality/features. Can anyone suggest one or know where
the source might by laying around? I thought I had heard ages ago about some
microcomputer C compilers being well under 32K.
Hmmmm.
Not sure of the parameters, but take a look at "Small C" by James Hendrix,
published by DDJ.
There were several C compilers that ran on CP/M, where the TPA
is no more than twice the size that you want. Those included Aztec/Manx,
and BDS C by Leor Zolman - didn't he recently release it into public domain?
IIRC, BDS C did not have floating point support; but you're better off
without that anyway.
10 a.m.
Jay West wrote:
I am looking for full source code for a *VERY* tiny C
compiler written in
any common assembly language. I'm much more concerned with size of the
compiler than functionality/features. Can anyone suggest one or know where
the source might by laying around? I thought I had heard ages ago about some
microcomputer C compilers being well under 32K.
As to how this relates to classiccmp... well.. *blush* I'm actually thinking
of porting C to the HP2100. The whole thing has to fit in 32K of ram,
including drivers, etc. Not sure what OS it will be placed on, perhaps
HP-IPL/OS. Might make a simple native OS for it or might even make it
standalone, not sure yet.
C requires a stack pointer and a index register.Offhand I don't think
your hardware supports that.
The Honeywell H316 had a high level langauge PL516
that might be easyier to port.
http://www.series16.adrianwise.co.uk/
The PDP-8 is said to have a pascal compiler, that may
be another idea.
Ben.
10:31 a.m.
It was written....
C requires a stack pointer and a index
register.Offhand I don't think
your hardware supports that.
I don't see why that couldn't be implemented
in software, or simply put into
custom microcode for the 2100. However, in actuality, I will likely be doing
this (If I take up the project) on a 21MX/E.
Jay West
---
[This E-mail scanned for viruses by Declude Virus]
1:09 p.m.
Jay West wrote:
It was written....
Well the computer in the hand is worth two at e-bay. :)
Since you have the hardware, good luck with the project.
C requires a stack pointer and a index
register.Offhand I don't think
your hardware supports that.
I don't see why that couldn't be implemented in software, or simply put into
custom microcode for the 2100. However, in actuality, I will likely be doing
this (If I take up the project) on a 21MX/E. Jay West
---
[This E-mail scanned for viruses by Declude Virus]
13 Oct
13 Oct
5:25 a.m.
On Fri, Oct 10, 2003 at 01:00:32PM -0600, ben franchuk wrote:
Jay West wrote:
Certain HP2xxx do have index registers (the ones with the EIG instructions
IIRC), but guess how FORTRAN compilers handle indexed array accesses
(this is pointer math). There is FORTRAN for HPs, so it is possible
(there are microcode extensions for HP1000 to speed up multiple dimensional
array acesses, but you don't really need them in all cases).
There is C for the HP/1000 available from interex.org (HP1000 CSL) which
has been released some time ago. This was written for RTE-IVB or RTE-6/VM,
it might be portable to pre-MEF machines.
C does not need a stack pointer although the original PDP implementaions
took advantage of it. It is attractive to base one's parameter passing
on a stack data structure, including recursion, but you can always
replace this by different structures for housekeeping.
I am looking for full source code for a *VERY*
tiny C compiler written in
any common assembly language. I'm much more concerned with size of the
compiler than functionality/features. Can anyone suggest one or know where
the source might by laying around? I thought I had heard ages ago about some
microcomputer C compilers being well under 32K.
As to how this relates to classiccmp... well.. *blush* I'm actually thinking
of porting C to the HP2100. The whole thing has to fit in 32K of ram,
including drivers, etc. Not sure what OS it will be placed on, perhaps
HP-IPL/OS. Might make a simple native OS for it or might even make it
standalone, not sure yet.
C requires a stack pointer and a index register.Offhand I don't think
your hardware supports that. The Honeywell H316 had a high level langauge PL516
that might be easyier to port.
http://www.series16.adrianwise.co.uk/
The PDP-8 is said to have a pascal compiler, that may
be another idea.
Pascal, in particular because of its procedure nesting, and thus
a rather tricky way of accessing variables in higher-level scopes,
is much more relying on a stack than C does. The PDP-8 and the HP2xxx
are with this respect both dumb in a similar way. And if it works with
a PDP-8....
Holger
16 Oct
16 Oct
11:34 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 352 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20031016/fe61b4ea/at…
12:20 p.m.
Tony Duell wrote:
Err, self-modifying code? That was the traditional way to do this sort of
thing.
I think the PC is noted more more self-modifying code than the old
machines. The only real self modifying code (on your typical early
machine) is the fact the return address is placed in the first word
of subroutine code.
C requires a stack pointer and a index register.Offhand
I don't think
your hardware supports that.
Certain HP2xxx do have index registers (the ones with the EIG instructions
IIRC), but guess how FORTRAN compilers handle indexed array accesses -tony
17 Oct
17 Oct
12:28 p.m.
Oh no, many HP boot loaders use self modifying code.
Take a look at the source for the H 264X terminal boot rom, it alters an
instruction by
using it as the target for an increment-and-skip-on-zero instuction. HP
took great pains
to squeeze some boot loaders into only 64 words. As a result you have
to reload these
loaders from ROM each time they run.
ben franchuk wrote:
Tony Duell wrote:
Err, self-modifying code? That was the traditional way to do this
sort of thing.
I think the PC is noted more more self-modifying code than the old
machines. The only real self modifying code (on your typical early
machine) is the fact the return address is placed in the first word
of subroutine code.
C requires a stack pointer and a index
register.Offhand I don't
think your hardware supports that.
Certain HP2xxx do have index registers (the ones with the EIG
instructions
IIRC), but guess how FORTRAN compilers handle indexed array accesses -tony
16 Oct
16 Oct
12:28 p.m.
> > C requires a stack pointer and a index
register.Offhand I don't think
> > your hardware supports that.
Actually.... I happen to have obtained years
ago an HP firmware board which
has user written microcode on it specifically for implementing stack
operations. Comes with a 1/2 inch thick set of notes by the person at the
university lab who wrote the code :)
I had forgotten that I had a copy of the book "Hendrix: Small-C"... until I
saw the responses to this thread. So I went running to my favorite bookshelf
where I kept it next to Rheingolds "data structures"... and my small-c book
is gone :( Must have loaned it over the years. Anyone happen to have a spare
copy? I looked at a few used book places online and didn't see it :\
Jay West
---
[This E-mail scanned for viruses by Declude Virus]
17 Oct
17 Oct
12:24 p.m.
HP 21MX series CPU's do have index registers, but they are best left unused!
Standard HP instructions can perform the same operations FASTER than the
absurdly slow
X and Y index register functions.
Tony Duell wrote:
Err, self-modifying code? That was the traditional way to do this sort of
thing.
-tony
C requires a stack pointer and a index register.Offhand
I don't think
your hardware supports that.
Certain HP2xxx do have index registers (the ones with the EIG instructions
IIRC), but guess how FORTRAN compilers handle indexed array accesses
10 Oct
10 Oct
10:20 a.m.
A number of C compilers on small architectures have solved this problem by
having 2, sometimes 4, distinct compiling phases, and passing data through
temporary files. This gives you a lot more leeway in code space. I've seen
preprocessor pass, tokenization pass, code generator pass, and in some cases,
the 4th pass is the assembler (which I generally prefer over
direct-to-assembly, since you can insert a user-written processing phase if
you want to get funky).
--John
On Friday 10 October 2003 14:14 pm, Jay West wrote:
I am looking for full source code for a *VERY* tiny C
compiler written in
any common assembly language. I'm much more concerned with size of the
compiler than functionality/features. Can anyone suggest one or know where
the source might by laying around? I thought I had heard ages ago about
some microcomputer C compilers being well under 32K.
As to how this relates to classiccmp... well.. *blush* I'm actually
thinking of porting C to the HP2100. The whole thing has to fit in 32K of
ram, including drivers, etc. Not sure what OS it will be placed on, perhaps
HP-IPL/OS. Might make a simple native OS for it or might even make it
standalone, not sure yet.
Did I recently post about being overcomitted? heh
Jay
---
[This E-mail scanned for viruses by Declude Virus]
10:33 a.m.
J.C. Wren wrote:
A number of C compilers on small architectures have
solved this problem by
having 2, sometimes 4, distinct compiling phases, and passing data through
temporary files. This gives you a lot more leeway in code space. I've seen
preprocessor pass, tokenization pass, code generator pass, and in some cases,
the 4th pass is the assembler (which I generally prefer over
direct-to-assembly, since you can insert a user-written processing phase if
you want to get funky).
Most of the C-compliers I have seen for 8 bit machines, tend to cross
compile from a PC. A PC is a far different machine with 32 meg and a
hardisk, rather than 32k and paper tape like the HP could be.
--John
12:34 p.m.
no the hp can have a hard drive!
----- Original Message -----
From: "ben franchuk" <bfranchuk(a)jetnet.ab.ca>
To: <General Discussion :>; "On-Topic and Off-Topic Posts"
<cctalk(a)classiccmp.org>
Sent: Friday, October 10, 2003 12:33 PM
Subject: Re: TinyC, port to HP
J.C. Wren wrote:
> A number of C compilers on small architectures have solved this problem
by
> having 2, sometimes 4, distinct compiling phases,
and passing data
through
> temporary files. This gives you a lot more
leeway in code space. I've
seen
> preprocessor pass, tokenization pass, code
generator pass, and in some
cases,
> the 4th pass is the assembler (which I generally
prefer over
> direct-to-assembly, since you can insert a user-written processing phase
if
you want to
get funky).
Most of the C-compliers I have seen for 8 bit machines, tend to cross
compile from a PC. A PC is a far different machine with 32 meg and a
hardisk, rather than 32k and paper tape like the HP could be.
--John
11:54 a.m.
J.C. Wren wrote:
> A number of C compilers on small architectures have solved this problem
by
> having 2, sometimes 4, distinct compiling
phases, and passing data
through
> temporary files. This gives you a lot more
leeway in code space. I've
seen
> preprocessor pass, tokenization pass, code
generator pass, and in some
cases,
> the 4th pass is the assembler (which I
generally prefer over
> direct-to-assembly, since you can insert a user-written processing phase
1:17 p.m.
Hendrix always seems to get the credit for Small C but the original
compiler was written by Ron Cain and published in an early issue of Dr.
Dobbs Journal. The earlier version by Ron Cain was quite a bit smaller
than Hendrix version.
On Friday, October 10, 2003, at 04:54 PM, jim wrote:
I ported Hendrix tiny C from my Imsai (CP/M version 1.4 actually) to a
mini
computer that had no c support in the early 80's when it first came
out.
If I recall it came in two passes as mentioned, and then an assembly,
then
link.
There was a c library support as well.
I actually didn't to go assembly for the mini, but actually to an
interpreted
language like Java uses now. I think I had to implement around 30
opcodes
total to implement the instructions used by the hendrix compiler.
that means
that of all the 8080 instructions that the original hendrix compiler
emitted,
there
were only 30 total used.
It supports a 16 bit address space natively, so would produce good
code on
your HP.
A typical pass was as follows:
run C0 on the c source
run C1 on the result of C0
merge the source for the clib (which was earlier run thru C0 and C1)
with
this output of C1.
Assemble the whole mess with an assembler that assembled to a
relocatable module.
take relocatable module, and use load command to suck into interpreter
on target machine (which was written in assembly).
I don't know about running in 32k. That probably would be tight to
run the compiler. I think the full C lib was around 24k long, but it
may
have been smaller. Since i linked in the whole mess w/o any way to
pick and choose what was used vs what was not, it was allways
there regardless. A better linker and better way of merging in the
clib could fix that.
the machine I had had a symbolic assembler that was easy to gen up
the assembler used here w/o any work so I didn't optimize that at
all.
As to optimization, you do have to do some duplicate elimination,
but other than that, it produced pretty good code.
most of the work on the hendrix c compiler was to the C1 pass,
which emitted the 8080 instructions. I don't recall whether the
Hendrix Tiny C was orignally for the 8080 / CP/M environment,
or whether the published version was a port from some other
environment, but the one I worked from ran on either CP/M 1.4
or 2 or 3x cpm's. the clib was pretty brain dead.
Jim
J.C. Wren wrote:
> A number of C compilers on small architectures have solved this
> problem
by
> having 2, sometimes 4, distinct compiling
phases, and passing data
through
> temporary files. This gives you a lot more
leeway in code space.
> I've
seen
> preprocessor pass, tokenization pass, code
generator pass, and in
> some
cases,
> the 4th pass is the assembler (which I
generally prefer over
> direct-to-assembly, since you can insert a user-written processing
> phase
1:44 p.m.
David Betz wrote:
Hendrix always seems to get the credit for Small C but
the original
compiler was written by Ron Cain and published in an early issue of Dr.
Dobbs Journal. The earlier version by Ron Cain was quite a bit smaller
than Hendrix version.
I found the original version easyier to understand and change. The
Hendrix if remember right also had more copywrite protection than the
original. I allways found it intersting that the 8080 instruction set
had to used rather than the 8086 instruction set on the PC.The 8086
instruction set seems to Pascal rather than C based.I don't think
C/UNIX would have developed as fast as it did if did not have a well
designed machine like the PDP-11.(my only gripe is bytes are not 9 bits
wide )
Ben.
12:23 p.m.
On 2003.10.10 20:14 Jay West wrote:
I am looking for full source code for a *VERY* tiny C
compiler
The C compiler from UNIX Version 6?
The PCC compiler from 2.9BSD UNIX?
Can anyone suggest one or know where
the source might by laying around?
This stuff is available via http://www.tuhs.org/
go into the archive,
PDP-11/Distributions/research/Dennis_v6 and
PDP-11/Distributions/ucb/2.9BSD
I thought I had heard ages ago about some
microcomputer C compilers being well under 32K.
This stuff (well, at least V6) was
used on 16 bit machines with less
then 64 kB of RAM.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
7618
days inactive
7625
days old
17 comments
11 participants
participants (11)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
bshannon＠tiac.net -
cisin＠xenosoft.com -
dbetz＠xlisper.mv.com -
esharpe＠uswest.net -
holger.veit＠ais.fhg.de -
jcwren＠jcwren.com -
jkunz＠unixag-kl.fh-kl.de -
jwest＠classiccmp.org -
jwstephens＠msm.umr.edu