From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-10-07 16:28:08
On Mon, Oct 07, 2002 at 04:01:41PM +0200, ruud.baltissen@abp.nl wrote:
> Then this question: what is against moving used blocks to fill up the free
> blocks? The only reason I see is that it will cost time.
It will not only cost time. You do also need to add code which moves the
blocks around. And, because you change the addresses of blocks that are known
to client functions, all clients have to access these blocks using indirect
pointers (pointers to pointers) which is slow and generates larger code. But
even this is not the biggest problem. The real problem is that your approach
is very error prone. Assume that someone who writes a pascal program does not
use the double indirection in one place. This will lead to all sorts of nasty
problems: Memory overwrites, including overwrites of executable code. Or,
assume someone has allocated a buffer that is used in an interrupt handler.
This interrupt handler may execute while your heap management is moving blocks
around.
The problem with these errors are that they may occur randomly and are very
difficult to track down.
> Mine is intend to run on a PC in the first place anyway so I choose for a
> good compiler in the first place. And a good compiler will eat memory. So to
> be very honest, I have my doubts if it will run on low-memory machines at
> all. And I wonder if it is worth to put a lot of effort in making it run on
> one. But I would be happy if it can run on my 720.
The 720 has just 64K of linear memory, and when using this memory, you have to
run it in a bank where the complete kernal is unavailable(!). Without a really
big effort, it is not possible to automatically generate code for a banked
system like the 720 to use more than one bank. So for programs that are not
specially crafted, the 720 is not better than a simple C64 in terms of
available memory.
Regards
Uz
--
Ullrich von Bassewitz uz@musoftware.de
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.4.