KickC Optimizing C-Compiler now supports Commander X16

[TomXP411]

On 1/18/2021 at 11:24 PM, Jesper Gravgaard said:

I am glad you got everything to compile! How ASM and C works together can still use some work - both improvements of the features allowing for for inlining ASM easily and the documentation of how you use it.



I believe that is a good starting point! 



If they are common enough to be easily portable to the other commodore platforms maybe they should be called cbmopen, cbmgetc, ...

I took a look at CC65 Tuesday evening, and I found their versions of those functions. 

The wrapper functions that simply invoke the KERNAL call are prefixed with cbm_k_, and the aggregate functions (ie: "open") are prefixed with cbm_

So that's the convention I will adopt. It's a little verbose and awkward to type, but I'd like to be able to compile the same code on cc65 or KickC without needing to make any changes. 

 

[Jesper Gravgaard]

9 hours ago, TomXP411 said:

So that's the convention I will adopt. It's a little verbose and awkward to type, but I'd like to be able to compile the same code on cc65 or KickC without needing to make any changes.

That is a good choice!

[SlithyMatt]

Mmmm... standardized C APIs. Me gusta!

[svenvandevelde]

Guys ... You want to use something very important in the compiler!

The following directive is mandatory to be used:

#pragma zp_reserve(0x80..0xA8)

 

This directive ensures that you are not using zero page registers which are used by the X16, but only when not using any BASIC or floating point!

When you use BASIC or floating point, use this pragma:

 

#pragma zp_reserve(0x80..0xFF)

 

See the following extract from the manual:

 

This is the allocation of fixed RAM in the KERNAL/BASIC environment.

Addresses	Description
$0000-$007F	User zero page
$0080-$00FF	KERNAL and BASIC zero page variables
$0100-$01FF	CPU stack
$0200-$03FF	KERNAL and BASIC variables, vectors
$0400-$07FF	Available for machine code programs or custom data storage
$0800-$9EFF	BASIC program/variables; available to the user

The following zero page locations are completely unused by KERNAL/BASIC/FPLIB and are available to the user:

Addresses
$0000-$007F

In a machine language application that only uses KERNAL (no BASIC or floating point), the following zero page locations are also available:

Addresses
$00A9-$00FF

This is the allocation of banked RAM in the KERNAL/BASIC environment.

Bank	Description
0	Used for KERNAL/CBDOS variables and buffers
1-255	Available to the user

(On systems with only 512 KB RAM, banks 64-255 are unavailable.)

During startup, the KERNAL activates RAM bank 1 as the default for the user.

 

When your program is growing, (like mine), it will consume a lot of zeropage registers.

Just ensure that you use the #pragma at the start of your program, or the kernal will start consuming zero page addresses in the 80-FF space,

which basically will erase local variables you've setup, with unexpected results. I had this problem and just could not understand why.

(when my program got bigger i only got into this problem).

But i started to debug the zeropage and saw that the kernal was overwriting some of the local variables (file I/O kernal routines), which were allocated at zero page $8D ...

So, hopefully you'll see this message and you'll take note!



It took me 3 weeks to get to this understanding ... I also have seen that the vera card lib additions are using a lot of zero page addresses, so i need to recode some of the variables.

 

 

[svenvandevelde]

Another note ... global variables should be minimized ...

When declaring global variables of the byte or char type, kickc will allocate these variables in the zero page space, which is a good technique to allow for speed execution.

However ... when having a lot of global variables, it seems that the zero page range fills up quickly! So minimize the amount of local variables. I see this now in my implementation of conio for the X16, which I'm now reworking to fix this issue.

Conio is declaring too many global variables. Instead, I will solve this with a global struct {} that will occupy just one zero page register ...

[SlithyMatt]

1 hour ago, svenvandevelde said:

The following zero page locations are completely unused by KERNAL/BASIC/FPLIB and are available to the user:

Addresses
$0000-$007F

Note that this is only the case in the mainstream emulator. The hardware uses $00 and $01 for bank switching, and there is a branch of the emulator that does this as well, and eventually that will be merged into a release build. So, you really only have $02-$7F, but if you plan on using any Kernal subroutines that use the zero page 16-bit "registers", you want to exclude those too. That really brings your availabe addresses to $22-$7F. For maximum reusability, you'll want to keep within that part of the zero page.

[svenvandevelde]

1 hour ago, SlithyMatt said:

Note that this is only the case in the mainstream emulator. The hardware uses $00 and $01 for bank switching, and there is a branch of the emulator that does this as well, and eventually that will be merged into a release build. So, you really only have $02-$7F, but if you plan on using any Kernal subroutines that use the zero page 16-bit "registers", you want to exclude those too. That really brings your availabe addresses to $22-$7F. For maximum reusability, you'll want to keep within that part of the zero page.

OK! Thank you, that is very useful information. That should be added in the documentation actually!

[SlithyMatt]

1 hour ago, svenvandevelde said:

That should be added in the documentation actually!

It has been if you look at the Rev2 branch

[svenvandevelde]

8 hours ago, SlithyMatt said:

It has been if you look at the Rev2 branch

Heum ... Sorry @SlithyMatt but where do i need to search for this? there might be other additions that may be useful.

[SlithyMatt]

5 minutes ago, svenvandevelde said:

Heum ... Sorry @SlithyMatt but where do i need to search for this? there might be other additions that may be useful.

https://github.com/commanderx16/x16-docs/tree/board_r2