Re: oo2c port for nmos6502
- From: Stewart Greenhill <nospam@nospam>
- Date: Tue, 06 Mar 2007 17:11:59 +0900
Hi Norayr,
Do you find that cc65 generates compact code for the 6502? Many of these
platforms have quite small amounts of RAM, so it would need to be
efficient to be feasible in the first place.
Yes, reasonably compact. The size of helloworld program in C using
cc65 is 2kb, in Oberon with cc65 as a portable asm - 3kb
ooptest.mod module which deployed with the oo2c port compiles into 4
kb binary
Moreover, using cc65 in-line assembly it is possible to write very
compact libraries, therefore produce much more compact binaries
OK. It looks like there is not too much overhead. Of course there is a
certain amount of library code required just to implement C data types
(eg. 16-bit, 32-bit ints with arithmetic ops, etc) which is unavoidable.
Once you start doing OOP, some of these data types will probably be
pulled in by the generated type descriptors.
Probably one place for optimisation is in method dispatch. Dynamic
type-bound method calls are via a double indirection which will probably
generate quite a bit of code on an 8-bit CPU.
Are you interested in retrocomputing, and/or do you have a particular
application in mind?
Yes, I interested in retrocomputing, yet my interest hardly could be
described as a nostalgie
I believe that 1mhz 6502 is fast processor, and 48-64k of ram is a big
memory (my first computer had only 32 kb of ram)
Even famous Lilith workstation developed at ETH had 64 kb of memory!
That old time, when men were real men, women were real women, and
small fuzzy creatures from alpha centaury were real small fuzzy
creaturs from alpha centaury,
were developed real software masterpieces by real software engineers
and computer scientists
I think is probably true that as computers get faster the quality of
software becomes worse. On slow/small machines we need to employ skill
and ingenuity to make things work well; on big/fast machines its much
easier for naive and inefficient implementations to be "good enough". As
the capacity of machines increases the quality of code tends to go down
so that its performance remains more-or-less constant.
My workstation at home is an old 120 mhz notebook with only 32
mb of ram
Needless to say, it runs Native Oberon impressively fast, and a custom
minimalist linux which I have compiled with pentium optimizations
Besides, latest Debian works well on it too
Proposal to use nmos6502-oo2c not just for fun:
NES machines produced even now, and they became very cheap, may be it
is possible to use NES for some kind of embedded systems :)
I don't know much about the NES, but I've always thought that a GameBoy (basic or advanced) would make a nice embedded system controller. They already have a display and keyboard (of sorts) and there are 3rd party development kits (cross-compilers, etc). The original GB has some kind of Z80 CPU, whereas the GBA has a 32-bit ARM7 CPU.
I tinkered a little with targetting 8-bit AVRs, but I think for a
serious application on microcontrollers one has to deal properly with
the dual address spaces (Harvard architecture).
You have done great work
Don't you plan to hack oo2c second branch and prepare avr minilib for
modern avr-libc?
No plans at present, although that might change if I have to do some more embedded systems work.
AFAIK, the only other
implementation of Oberon-2 for an 8-bit machine is Christoph Regli's
uOberon (micro-Oberon) which targets the 8051
I did not find any sign of it in the net except an old usenet thread
Is it possible to view it's source?
I have only ever seen the project documentation. I don't think the source is available. You would probably have to contact ETH, or the original author.
I want to became a good compiler construction specialist and compilers
are mystrongest interest - besides I am writing my own Oberon SA
compiler for avr
and my own compiler for 6502 ;) Both are not published yet - and
helloworld produced by last is only 200 bytes in size :)
thank you again
Sounds very interesting. I hope that you continue sharing your work and your findings.
Of course, compilers for small machines are always more challenging to implement well. Its not only necessary to generate very compact code, but you often have limited resources which need to be carefully managed. I don't know much about Oberon SA, but one of the features lacking in Oberon-2 is structured constants (arrays, records, etc). I've used various versions of C for embedded systems and these generally have some mechanism for allocating arrays and structures in ROM or program-space. On machines with dual address-spaces (like the AVR) there are basically four different types of pointers:
data -> data
data -> program
program -> program
program -> data
This requires pointers to have attributes that are handled properly not just by the code generator but by the type system. So its probably inevitable that Oberon for an AVR would need some extensions to the standard Oberon language model.
Cheers,
Stewart
.
- Follow-Ups:
- Re: oo2c port for nmos6502
- From: gnorayr
- Re: oo2c port for nmos6502
- Next by Date: Re: oo2c port for nmos6502
- Next by thread: Re: oo2c port for nmos6502
- Index(es):
Relevant Pages
|
