Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

61 Excellent

1 Follower

About JesperGravgaard

  • Rank
    Space Invader

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, The author of KickC here. @ivop and @ilmenit are correct that the goal is not to be a drop-in replacement for cc65. What I really want to create is a compiler that allows a programmer who knows C an easy way to get started on any 6502-platform, to be able to create C-programs that runs as fast or faster than naively coded ASM, and finally to be able to seamlessly switch to optimized ASM for any performance-critical parts. The semi-prioritized goals of KickC could be stated as: 1) Generate optimized and readable 6502-family ASM. 2) Support different existing 6502-based hardware platforms. 3) Allow the programmer to utilize the strength of KickAsm. 4) Be standard C compatible. However, it would be great if porting CC65 programs to KickC was pretty easy to do. For instance CC65 and KickC can and should have a bunch of libraries that are compatible. An existing example of this is the <conio.h> library. If anyone wants to contribute an implementation of <fcnlt.h> or any other standard C / cc65 library for Atari 8bit I will gladly merge it into the KickC master and include it in future releases. Feel free to reach out to me with any questions. /Jesper
  2. KickC version 0.8.5 adds a number of improvements and new features. Of specific interest for the Atari 8bit it adds support for creating "real" XEX-files with multiple segments - supporting both run-address and init-addresses. This is achieved through a new KickAss linker plugin https://gitlab.com/jespergravgaard/kickass-plugin-atari-xex. The plug-in was developed in cooperation with @fenrock Get the new release here: https://gitlab.com/camelot/kickc/-/releases
  3. None of those LAXes are opcode $AB LAX #IMM. They will become $A7 LAX ZP or $AF LAX ABS. The AXS #IMM will become a $CB SBX #IMM. Neither of these are marked as unstable in https://xxl.atari.pl/sally-6502c/, so these fragments should not present any problem
  4. @fenrock Very nice table! However, I have looked through all the compiler fragments, and I cannot find any fragments in the compiler using LAX #n. Could you point me towards the 2 fragments you have found? I have looked through several articles on the illegal opcodes. There are several (old) articles that have contradictory information about how they work. Some of the best sources I could find are http://visual6502.org/wiki/index.php?title=6502_Unsupported_Opcodes and http://www.oxyron.de/html/opcodes02.html. I have so far never seen well-documented examples of undocumented opcodes that work differently on different CPU's. Are you certain that any of the codes on SALLY actually works differently from an original MOS 6502? If anyone has confirmed this I would love a link to more information! My understanding so far is that all the CPU's where the undocumented opcodes work actually contain an almost exact copy of the original MOS 6502 core (transistor by transistor). See for instance this die shot of a NES RP2A, where you can see the 6502 core in the lower right corner http://www.visual6502.org/images/pages/Nintendo_RP2A_die_shots.html. Here is an original 6502 die shot to compare with http://www.visual6502.org/images/6502/index.html. A die shot of SALLY is on their TODO-list - so when that arrives we can check it out
  5. @Dmitry From the ASM fragment you posted it seems the code continues at label __b99 (elsewhere in the ASM-file). Here I would expect the AF2-comparison. So to understand the problem you are experiencing I would need to se more of the resulting ASM-file. Also, the compiler can detect code that is never run - and remove it. For instance if your AF3 is constant !=0 and <=56 then the compiler will delete the body of the if(). So to understand your problem completely it would also be necessary to see more of the C-file. If you can share more details with me I would love to understand your problem, and if there is an error in the compiler I will of course fix it! /Jesper
  6. I just had a go at https://adventofcode.com/ . That looks like a lot of fun! I solved the first challenges in KickC running on Atari 8bit
  7. @fenrock That is a very nice demonstration of the new XEX format! The next release of KickC will include this linker plugin to make it easier to create better XEX files directly from KickC. If anyone want to use it before it is released officially it is always possible to download the newest master build from https://gitlab.com/camelot/kickc
  8. This is how I usually initialize a char[] to the contents of a binary file. export char TILES[] = kickasm(resource "smb1_chr.bin") {{ .import binary "smb1_chr.bin" }}; If you know the size of the file to be 3840 you can help the compiler by specifying that export char DATA[3840] = ... A final note: The export keyword is not needed if your code uses the DATA array. It is only needed if you want to include the data in your program even if the code does not use it.
  9. @Gury You have found a bug in the current version of KickC! The code loading source files looks through a list of search folders - but does not consider that the file name may be absolute. I have fixed it, and the fix will be in the next release. https://gitlab.com/camelot/kickc/-/issues/576 Thank you for finding the problem!
  10. I have created a KickAssembler plugin to support the XEX file format. You can get that here if you like to code code ASM: https://gitlab.com/jespergravgaard/kickass-plugin-atari-xex I have also integrated the plugin into KickC. So in the next release KickC will be able to create XEX-files where each memory block is stored as a seperate segment in the XEX-file. This will help you to get smaller XEX-files if you for instance have some code in $1000 and some data in $3000 with an empty gap in between.
  11. I really like the Mad Pascal benchmark suite! The different tests examine different aspects of the language nicely. However, I am somewhat unsure in which tests "higher is better" and in which "lower is better". Is there a list showing this somewhere, that I have missed? @zbyti maybe you can point me in the right direction.
  12. @Blues76 Here are some of the differences. The most significant difference is the modern compiler optimization techniques KickC uses to generate fast ASM from your C-code. A second difference is that KickC can generate very small binaries, since it only includes code for the functions that are actually used. This includes functions in libraries. If you include a library and only use a single function the compiler will only generate ASM for that one function. It even optimizes the library functions based on the parameters you pass, so if you only call the library function once or always pass the same parameters it will optimize the ASM based on the constant parameter. A third difference is that the generated ASM is very readable, so you can directly compare your C-program to the ASM it generates. As an example This C-code: https://gitlab.com/camelot/kickc/-/blob/master/src/test/kc/examples/atarixl/rasterbars.c compiles to this ASM-code: https://gitlab.com/camelot/kickc/-/blob/master/src/test/ref/examples/atarixl/rasterbars.asm A minor difference is the ability to initialize data structures using inline KickAssembler macro code. Kick Assembler has a great macro language, so this allows for very easy initialization of look-up tables. char SINTABLE[0x100] = kickasm {{ .fill $100, round(127.5+127.5*sin(2*PI*i/256)) }}; CC65 on the other hand is a lot more mature than KickC. It very rarely fails. It has better library support. There are more examples and information available online.
  13. @fenrockKickC already supports putting functions into different named segments using #pragma code_seg(name). Here is a tiny example where the main() function is in the default "Code" segment and the fillscreen() function in the "CodeHigh" segment. https://gitlab.com/camelot/kickc/-/blob/master/src/test/kc/examples/linking/linking.c You can also choose which segment data ends up in using #pragma data_seg(name)
  14. Thank you for the suggestions @ivop I do plan to change align() to __align()in a future release. Most of the other non-standard modifiers already use the __ prefix. https://gitlab.com/camelot/kickc/-/issues/572 I also have a plan for better support for "empty" data structures, which currently generates zeros into the binary file. https://gitlab.com/camelot/kickc/-/issues/545 The Atari 8bit-platform XEX-format is unique in supporting multiple memory segments in a single binary file. It is currently possible to write your own linker definition in KickC, and by doing that and using #pragma data_seg() / #pragma code_seg() you can generate XEX-files with multiple segments. Maybe I could find a way for the compiler to automatically generate the linker configuration needed for creating a XEX-file with multiple segments. However, I have not currently planned that feature, since I am unsure how I can find a good general solution for adding it. /Jesper
  15. KickC tries to optimize the code as well as it can by analyzing the code thoroughly to identify variables that are actually constants. One of the methods is uses is converting the entire program to single static assignment form, which effectively changes the program (by introducing new variables) to ensure that each variable is only assigned once. This makes the compiler quite good at constant detection. However, it will compile faster and leave less room for mistakes if the programmer marks pointers as constant. Also @ivop has a point on creating portable code. Even with the best current compiler methods, nothing beats a programmer that has a thorough look at the code and rewrites it to achieve optimal performance.
  • Create New...