From: Ojala Pasi 'Albert' (albert_at_cs.tut.fi)
Date: 2002-10-08 14:32:04
> and they are needed on each access, because the pointer cannot be cached (it
> may change between two accesses)!
Actually for non-multitasking machine it is a fair assumption that between
two function calls (specifically a memory allocation/free call) the memory
doesn't jump around and you can cache everything imaginable... Even for a
multitasking arrangement you can make the allocation behave like that.
Still, I too support the easier "let it fragment and let the programmer
worry"-approach..
Ruud:
> > All the above covers data manipulation. For one problem I still haven't
> > found solution: what if the executable code doesn't fit inside the first
> > bank? (The first thing that came to my mind: Use another computer !!!)
Limit the size of one function to 64k and use a longer calling convention
for jumps between pages.. I have done that in a C-compiler for a DSP.
The programmer doesn't know a thing, although one function call takes
now 5 instructions instead of one. Jumps inside a function take the same
as before.
But yes, worry about getting something useful first :-)
> To make it useful, you will have to add at least a small peephole optimizer,
> otherwise code generated by such a simple compiler will just crawl.
That would help a lot so that you can generate the code the same way
always and only then optimize. Generating code directly for a lot of
special cases becomes very fast very hard to maintain, although pascal
is very, very, very simple compared to C.
> Plus backend tools that support modularization and relocation.
Borrow those from cc65 or ACME, or whatever supported this?
-Pasi
--
"Maybe the doc's right. Embrace the moment. In the end, that's all we have.
Trouble will come in its own time, it always does. But that's tomorrow.
Give me today, and I *will* be happy."
-- Sheridan in Babylon 5:"Epiphanies"
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.4.