Author Topic: Hisoft-C and CALL (Amstrad CPC)  (Read 3487 times)

0 Members and 1 Guest are viewing this topic.

Offline FloppySoftware

  • CPC6128
  • ****
  • Posts: 243
  • Country: es
  • The best team: Amstrad PCW, CP/M, and the Z80 cpu.
    • Floppy Software
  • Liked: 234
  • Likes Given: 171
Re: Hisoft-C and CALL (Amstrad CPC)
« Reply #25 on: 09:11, 26 January 16 »
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.es < NEW URL!!!
cpm-connections.blogspot.com.es

Offline FloppySoftware

  • CPC6128
  • ****
  • Posts: 243
  • Country: es
  • The best team: Amstrad PCW, CP/M, and the Z80 cpu.
    • Floppy Software
  • Liked: 234
  • Likes Given: 171
Re: Hisoft-C and CALL (Amstrad CPC)
« Reply #26 on: 09:14, 26 January 16 »

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. :)
floppysoftware.es < NEW URL!!!
cpm-connections.blogspot.com.es

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.919
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 1132
  • Likes Given: 1902
Re: Hisoft-C and CALL (Amstrad CPC)
« Reply #27 on: 10:21, 26 January 16 »
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.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Offline FloppySoftware

  • CPC6128
  • ****
  • Posts: 243
  • Country: es
  • The best team: Amstrad PCW, CP/M, and the Z80 cpu.
    • Floppy Software
  • Liked: 234
  • Likes Given: 171
Re: Hisoft-C and CALL (Amstrad CPC)
« Reply #28 on: 11:48, 26 January 16 »

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.  8)
 
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]
myfunction()
{
 int varint;
 char varchar;
 int ptrint;
 char *ptrchar;
 varint = 1;
 varchar = 'A';
 ptrint = &varint;
 ptrchar = "String";
}

MESCC outputs this:
 
Code: [Select]
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.  ;)
 
floppysoftware.es < NEW URL!!!
cpm-connections.blogspot.com.es

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.919
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 1132
  • Likes Given: 1902
Re: Hisoft-C and CALL (Amstrad CPC)
« Reply #29 on: 06:13, 27 January 16 »


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.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Offline FloppySoftware

  • CPC6128
  • ****
  • Posts: 243
  • Country: es
  • The best team: Amstrad PCW, CP/M, and the Z80 cpu.
    • Floppy Software
  • Liked: 234
  • Likes Given: 171
Re: Hisoft-C and CALL (Amstrad CPC)
« Reply #30 on: 09:28, 27 January 16 »

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.
floppysoftware.es < NEW URL!!!
cpm-connections.blogspot.com.es

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.919
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 1132
  • Likes Given: 1902
Re: Hisoft-C and CALL (Amstrad CPC)
« Reply #31 on: 02:14, 28 January 16 »
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.

Quote
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.
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Offline Alcoholics Anonymous

  • CPC664
  • ***
  • Posts: 51
  • Country: ca
  • Liked: 44
  • Likes Given: 0
Re: Hisoft-C and CALL (Amstrad CPC)
« Reply #32 on: 22:58, 28 January 16 »
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.

Quote
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]
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]
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.
« Last Edit: 23:00, 28 January 16 by Alcoholics Anonymous »