26 Jan
2003
26 Jan
'03
9:08 a.m.
It was thus said that the Great acme(a)ao.net once stated:
I've done little Z80 assembly programming (a number of small utilities, all of
which were < 500 lines of code) but I've already written and tested *almost*
all the low-level functions (console, file, & printer i/o) which the program
requires. Except . . . how do I dynamically allocate memory? I don't see a
CP/M function call to allocate or free memory. Does such a function exist,
and if so, what are the details?
Lacking such a CP/M function, how do I write replacements for malloc() and
free()? It has to be possible or the calls would not exist in the library of
the compiler I used to build the C program.
Under CP/M it's the responsibility of the program to manage memory, not
CP/M; the C library you are using contains the code required to handle
memory management.
Unless you are doing this just for the intellectual exercise, it is
counter productive to rewrite a program from C to assembly just to save
memory [1] until you figure out *why* the program is running out of memory.
Is the data set too large to fit? If so, by how much? If it's only a few
kilobytes then see if you can't rework the code to be smaller. If you are
talking a few dozen kilobytes then perhaps a rethinking of how the program
works is in order. Or perhaps the program is holding onto data longer than
it really needs, in which case you'll need to rework how the program works.
Just changing the program to Assembly may not help you.
-spc (Been there, done that, have the unfinished programs ... )
[1] Usually it's speed and even then, you typically don't resort to
Assembly until you've already made algorithmic changes (for example,
switching from a Bubble Sort to Quick Sort) where you get the best
gains in speed. Only then do you switch to Assembly, and only after
you figure out which routines are sucking up the CPU and changing
only those routines to Assembly.