Looks like he's covering both bases by sending to m100@lists.bitchin.. and cc'ing m100@bitchin...
As a matter of fact I get three posts every time; I have two list accounts in case one has issues but for some reason only one gets the duplicates. Curious, yes, but I don't have a problem with it. ----- Original Message ----- From: "Daryl Tester" <dt-m...@handcraftedcomputers.com.au> To: <m...@bitchin100.com> Sent: Tuesday, June 13, 2017 8:35 AM Subject: Re: [M100] SmallC-85 library 0.0.5 upload > 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" <jho...@pobox.com> 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.
