Hello, Guest the thread was called1.7k times and contains 32 replays

last post from mega65 at the

KickC Optimizing C-Compiler now supports MEGA65

  • When I look at $EC it does not seem to contain the cursor column in my emulator (using a C65 ROM).

    To get the current cursor column in BASIC 10 direct mode, it's important that you print something before printing the "peek(236)", because a simple print command always starts at column 0:


  • You are probably right that the crash is related to the start-up memory configuration.

    Well the mystery is solved. As it turns out, I had left a kbhit() check in there to stop a running simulation. Somehow, in C65 mode, kbhit() is true after starting the simulation, and for some other reason, the normal screen mode is not restored correctly after that. So, that's why it didn't work in C65 mode.


    But it does now :) Here's a short clip of my trusty extreme-programming-partner Candor K. and me trying out the latest version:


    https://streamable.com/1i68oz


    (for those who don't know the previous cc65 based version...: it's 4-5 times faster and smaller. yayy)


    Now I'll just have to hack together a few keyboard input functions in order to be able to set the simulation parameters ;)

  • https://streamable.com/1i68oz


    (for those who don't know the previous cc65 based version...: it's 4-5 times faster and smaller. yayy)


    Now I'll just have to hack together a few keyboard input functions in order to be able to set the simulation parameters ;)

    Candor K looks like a very cozy extreme-programming-partner.

    Regarding the keyboard input there is a keyboard.h library included with KickC that interfaces directly with the CIA#1 at $DC00. I can't find info in the manual about whether the MEGA65 supports C64-style keyboard reading on CIA#1, but I guess it does. So maybe you can just use keyboard,h (while disabling CRAM2K before calling and enabling it again after calling).


    Alternatively it looks like the keyboard is mapped to $D610. I have not made any library routines for that yet.

  • Yep, I removed the kbhit() and built myself a nice little cgetc() using the accelerated keyboard scanner:


    Code
    1. byte *kbscan = 0xd610;
    2. char cgetc()
    3. {
    4. char res;
    5. while (*kbscan == 0);
    6. res = *kbscan;
    7. *kbscan = 0;
    8. return res;
    9. }

    Now I'm stuck at another point: At some point in my new code, there is:

    Code
    1. for (i = 0; i < numSharks; ++i)

    (where "numSharks" is a function parameter)

    to which KickC responds with

    Code
    1. Unknown fragment for statement [254] if((signed word) initWorld::i#7<(signed word)*((const word*) main::params+(byte) 3*(const byte) SIZEOF_WORD)) goto initWorld::@6
    2. Missing ASM fragment Fragment not found vwsz1_lt__deref_pwsc1_then_la1. Attempted variations vwsz1_lt__deref_pwsc1_then_la1
    3. File /home/stephan/devel/wator-kickc/./wator.c
    4. Line 361
    5. for (i = 0; i < numSharks; ++i)


    The funny thing is: When I call the function with a constant value, the line compiles without problems. I can't for the life of me figure out what's happening here... ?(

  • Code
    1. Unknown fragment for statement [254] if((signed word) initWorld::i#7<(signed word)*((const word*) main::params+(byte) 3*(const byte) SIZEOF_WORD)) goto initWorld::@6
    2. Missing ASM fragment Fragment not found vwsz1_lt__deref_pwsc1_then_la1. Attempted variations vwsz1_lt__deref_pwsc1_then_la1
    3. File /home/stephan/devel/wator-kickc/./wator.c
    4. Line 361
    5. for (i = 0; i < numSharks; ++i)

    The funny thing is: When I call the function with a constant value, the line compiles without problems. I can't for the life of me figure out what's happening here... ?(


    The ASM generation is based on finding an ASM fragment the implements a single super simple micro C-statement . For this it uses all the files in the /fragment/ folder and a fragment synthesizer that can make new fragments from existing ones.


    It can already handle a ton of different statements. However, occasionally you will hit something that it does not know how to turn into ASM. You have hit vwsz1_lt__deref_pwsc1_then_la1 - which is the fragment meaning if(vwsz1<*pwsc1) then goto la1 where vwsz1 is a signed 16-bit value stored on zeropage and pwsc1 is a constant valued pointer to a signed-bit value.


    If you put the attached file into the folder /fragment/mos6502-common/ then the code above compiles correctly. The fragment will ofc. also be included in the next release.


    The reason it works when you pass a constant is that KickC is pretty good at optimizing code before turning it into ASM - so it probably avoids the comparison altogether or compares with a constant in that case.


    Let me know if this works for you - and also please let me know if you hit any other missing fragments.

  • Jesper - I wonder if it makes sense to have some mechanism for KickC to attempt to "phone home" to find missing fragments, so that you can just put them up on web somewhere as you create them?


    Also, Jesper and I did some work a year or two ago on automatically generating fragments from their descriptions. If someone were interested in continuing that work, it would be quite helpful, I suspect.


    LG

    Paul.

  • I have been considering the phone-home mechanism myself also. It would be nice to be able to add fragments for people without them having to download the file and place it in the right folder. I will look into that.

    If anyone want to help create (through further developing the automatic tool or by hand-coding) some of the fragments the compiler still needs to learn they are more than welcome!

    Currently I very rarely encounter any missing 8bit-fragments, but for 16bit and 32bit (and mixed types) it still needs to lean a lot.

    /Jesper