Hisoft-C and CALL (Amstrad CPC)

[FloppySoftware]

I don't know why your version was slower, and I don't know if a larger prog would be proportionally slower, or if certain routines are slower while other routines might be faster, but just for this little prog the Hisoft is a bit faster, while the MESCC prog is smaller.   Take your choice!

Choice was taken years ago: small size won!

Take a look on how local variables are managed in MESCC. It is a good example of what I said.

Thanks for testing!

[FloppySoftware]

It sounds like MESCC is compressing the final COM file, which would in effect slow the result in order to Decompress the code.

See my reply to Geoff.

[AMSDOS]

See my reply to Geoff.

Which one?


Just saying if it takes longer to run and is smaller, then something is being compressed, though you sound sure it's not being compressed, you know MESCC better than I do.

[FloppySoftware]

Which one?


Just saying if it takes longer to run and is smaller, then something is being compressed, though you sound sure it's not being compressed, you know MESCC better than I do.

The last one, of course. 

For MESCC development, I always prefer small code generation over speed. That's fine for my projects. 

AFAIK, accessing local variables in C (in Z80 machines) has a big cost in code size. I try to generate less code for that, at a cost: less speed and some new routines in the C runtime library. For example:

Code Select Expand

myfunction()
{
int varint;
char varchar;
int ptrint;
char *ptrchar;
varint = 1;
varchar = 'A';
ptrint = &varint;
ptrchar = "String";
}

MESCC outputs this:

Code Select Expand

myfunction
DEC SP
PUSH BC
PUSH BC
PUSH BC
LD HL,1
CALL ccxpw
DEFB 5
LD HL,65
CALL ccxpb
DEFB 4
LD HL,5
ADD HL,SP
POP BC
POP DE
PUSH HL
PUSH BC
LD HL,a0+0
POP BC
PUSH HL
INC SP
POP BC
POP BC
POP BC
RET
a0
DEFB 83,116,114,105,110,103,0

Libraries are another source of big size in code. Unfortunately, MESCC doesn't use any linker but a simple (but effective) assembler. I try to improve this via #defines.

Of course, I could use Z88DK or SDCC, and enjoy their benefits (more ANSI compliant, better code generation...) but I would loss the pleasure of hacking the MESCC compiler and its libraries. 

[AMSDOS]

The last one, of course. 

Wasn't sure, cause your reply wasn't saying if compression was used or not. Would of been a clever way to compact code into a Compressed COM file or BIN, on a CPC Compressing code was done later on even though Screen Compression was probably one of the earlier methods of compression for it.

[FloppySoftware]

Wasn't sure, cause your reply wasn't saying if compression was used or not. Would of been a clever way to compact code into a Compressed COM file or BIN, on a CPC Compressing code was done later on even though Screen Compression was probably one of the earlier methods of compression for it.

That would have the advantages of less code size on disk and better loading speed (but involves decompression later), but once decompressed, the program will need same memory space, not less.

We could use LBR files for this (there are even program loaders for that kind of files), but I don't like that extra work  in a daily basis.

[AMSDOS]

That would have the advantages of less code size on disk and better loading speed (but involves decompression later), but once decompressed, the program will need same memory space, not less.

Naturally.

We could use LBR files for this (there are even program loaders for that kind of files), but I don't like that extra work  in a daily basis.

Yes, though I was wondering if something like MESCC could do all that automatically, I'm pretty sure I've seen a CP/M program which create a compressed COM file, so when you run that COM file, it unpacks itself, though I don't think I've seen a program run from a compressed COM file.

[Alcoholics Anonymous]

C wasn't standardized until 1989, so it's not overly surprising that 8 bit C compilers pretty much follow whatever rules suited them.

It didn't have a standard created by ANSI but K&R wrote the book that described their language and that's what was taken as standard before then.  The shortcomings in the 8-bit compilers were not due to any lack of standard.

Yes, though I was wondering if something like MESCC could do all that automatically, I'm pretty sure I've seen a CP/M program which create a compressed COM file, so when you run that COM file, it unpacks itself, though I don't think I've seen a program run from a compressed COM file.

It's pretty easy to do actually.  Here's a bit of code I used to decompress a stored binary image on cartridge into ram at startup.  It's using zx7 which is small, fast and pretty good on compression ratios.  There are a couple of other z80 compressors that can compress smaller in many cases but zx7 is very easy to use and is fast.

Code Select Expand


org 0

main:

   di
   
   ld hl,clisp_image
   ld de,28000

   EXTERN asm_dzx7_standard
   call asm_dzx7_standard
   
   jp 28000

clisp_image:

   BINARY "clisp_if2.img.zx7"


Program starts, decompresses the compressed image appended to the end to address 28000, then jumps to 28000.

You can do something similar with cp/m executables.  It's a little bit harder because you're decompressing into the same place where your compressed binary is located.  So you may have to copy the compressed block as high as you can in memory (just under bdos) and then decompress to the address just following the loaded routine before jumping into it.

Maybe something like:

Code Select Expand


org 0x100

main:

   ; copy compressed image to highest memory address possible
   ; use overlap-safe copy

   ld bc,cpm_image_end - cpm_image
   ld hl,cpm_image - 1
   add hl,bc
   ld de,(0x0006)
   dec de
   lddr

   ; decompress image to low memory

   inc de
   ex de,hl
   ld de,cpm_image

   call asm_dzx7_standard
   
   ; decompressed program follows
   ; just fall into it

cpm_image:

   BINARY "program.bin.zx7"

cpm_image_end:


You have to make sure you have enough stack (I think cp/m guarantees something like 8 bytes hidden inside bdos someplace).  zx7 is very light on stack so I think it's ok to use what bdos provides at startup.  You'll have to ORG your cp/m executable to the address "cpm_image".

Actually I might try to do something like this in z88dk.  As FloppySoftware says you don't gain anything in RAM space for the executable but you do save on disk space which might also be important.

If you want to decompress things as the program runs, that's easy to do too but it's up to the programmer to do that not the compiler.