Anyone else getting double postings from Willard?
The emails have the same message IDs, but slightly different paths
through the what looks like dreamhost's mail servers, but I would
expect that that would affect all mail, not just Willard's alone.
On 13/06/17 16:05, Willard Goosey wrote:
On Mon, 12 Jun 2017 16:38:28 -0700
"John R. Hogerhuis" <[email protected]> wrote:
Thanks, I got WLC.CO to build.
Thinking about extending HTERM with some Small-C code. It will be much
easier to code Cish than having to do everything in assembly. HTERM is
pretty bare bones mainly because of that.
Humm, an interesting idea.
Is there documentation on memory management?
Not really, because there basically isn't any memory management? Ok...
ASLINK and I don't really get along very well. I've sorta learned how
to sort of minimally get it to do what I need? The way it currently
seems to work, is that static data segments get intermixed with the
code (see the xxx.map file after final linking). As a UNIX d00d I
object philosophically. See "minihowto.txt" for about everything I know
about doing m100 assembly under ASX.
And then there's local variables on the stack. On the m100 the stack
starts somewhere below HIMEM and goes down (as normal .CO execution),
and hopefully doesn't grow enough to clobber files. Preventing this
would require the compiler to generate extra code, and frankly I'm
trying to stay OUT of the actual compiler.
Where do global and file scope allocations go?
Globals of the same "module" (IE SMALLC_GENERATED_DATA) will be grouped
together, after all the code sections of that module. This is ASLINK at
work again.
Can space be allocated on the stack other than automatic variables?
As long as you clean it up before you RET.
Is malloc/free implemented?
Nope. The full Small-C spec (I dug up the 1984 book!) calls for an
AVAIL() function that I should implement.
A Malloc arena would, properly, start immediately above RAM files and
grow upwards... Except that filespace can grow! Oops! I don't think
that's a place I want to go.
Also what are the rules for mixing C and assembly?
Arguements are on the stack *left* to *right*. All arguements are
16-bit values. It is standard Small-C behavior to pass the number of
arguments in A. Called functions do NOT preserve any registers. Any
returned value will be in HL. After a C function is called, the stack
should look exactly like it did before the function was called.
#asm is supported but I haven't really messed with it... See the CP/M
runtime included with the compiler for some neat tricks.
Willard
--
Regards,
Daryl Tester
Handcrafted Computers Pty. Ltd.
