Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by desertfish

  1. Seems like keeping the V39 (only) looks to be the best way forward, I'm happy with that. And @borgar makes a good point; if you don't actually use the parts that have changed your program still runs fine on v38.  I'll make sure this is clear in the documentation too

  2. For this assembler I'm assuming we have enough memory to
    a) store all source text files in memory simultaneously
    b) store the resulting machine code program in memory
    c) have enough memory for the parsing and symbol table (the assembling process itself).

    It's a 2-pass assembler so I think it should be possible to avoid having to use the stack of open files during the reads themselves. I think we could just read the files sequentially when the assembler encounters include instructions in phase 1. And use the stack only in phase 2 where actual machine code is generated.  This would reduce some complexity in the disk io routines (although the multi-file support across banked ram pages is still going to have to happen, rather than using one contiguous chunk of vera memory for storing the single source file currently)

  3. Good questions.  There's no runtime though: prog8 compiles down to machine code in the end, and while doing so it makes various assumptions about the target platform (cpu type, memory mapped i/o registers, and rom routine locations). For example the memory locations of the floating point routines in rom -which prog8 uses for its float types- have changed between v38 and v39 roms and this will make compiled programs crash when run on the other rom version.
    So basically, allowing for a compiler switch more or less requires introducing a third target machine definition in the compiler something which is pretty involved and is potentially going to duplicate a lot of code and library files.

    Apart from that, on the discord it was correctly pointed out that it would also introduce the expectation of backward compatibility,  which is complexity that I'm not wanting to go for.

  4. Ok wow
    Any idea about the quality of the program's code that it produces?

    Maybe eventually using llvm with all its advanced code optimizations as a backend for Prog8 isn't totally impossible...

  5. Poll.

    I'm contemplating reverting the Cx16 V39 changes that I have already made in Prog8, for the upcoming 7.0 release -- because the actual release of an official v39 emulator+roms is taking way longer than I anticipated.

    1. keep v39 support in Prog8 as it is. You're targeting  v39 already and can run it with a custom build of the emulator+roms as they are now on github
    2. revert back to v38 support because that is still the official cx16 release    (and put the v39 changes back in once the official cx16 release is there)
    3. make it selectable via a command line switch

    Which option would you choose and why?

  6. @Stefan that file stack tracking the line number count is a solid idea.

    @Scott Robison 10 files should be enough (tm) I'm glad to learn it is actually possible to keep multiple files open and read from each of them.   However maybe this isn't even necessary if we keep track of any import statements encountered along the way and executing them after the file they occur in has been fully read.

    Allowing multiple open files at the same time would also require changing prog8's diskio routines -- they assume a single open file channel (hardcoded)

  7. I would like to add a source and binary file including mechanism to the assembler, but that requires a total rewrite of the file I/O logic, to deal with multiple sources rather than one contiguous block of memory.  I also have no idea yet how to keep track of what file the currently parsed source line is coming from, if you're jumping between files due to includes.

  8. Yeah it didn't matter much. I suspect it is taking a lot of overhead somewhere to pickle/unpickle the data passed between the processes. And indeed, switching to multiprocessing.pool.ThreadPool didn't improve things.

    I see no obvious big improvements to the code as-is.

    But I think it would be worthwhile to investigate what happens if you split the problem up differently. Rather than dividing it over the tokens to search for, I suggest trying an approach where you split up the source image in strips of 8 pixels high and process each strip in a worker process. So one worker processes one line of characters.

    I realize this will require quite a bit of rewriting...

  9. Hey, great stuff!

    Yeah multiprocessing can be a bit iffy, it could be that much time is spent passing the data set across different processes to work on it, and passing the results back.

    To avoid this, multi threading could help, but then you're sometimes constrained by Python's Global interpreter lock.

    I want to take a look at your code and see if I can tweak it a bit to make it faster!   (for reference it runs in 5 minutes 30 seconds on my Ryzen 2700x)


    • Like 2
  10. I've just released a new 7.0-beta2 version of the compiler https://github.com/irmen/prog8/releases/tag/v7.0-beta2

    This version will likely be very close to the final 7.0 release because I'm not considering adding or changing anything new from now on (except bug fixes).

    Some of the most important fixes/changes since the previous beta release:

    • string encoding and string interning bug fixes
    • various compiler crashes fixed
    • %asminclude fixed (scopelabel argument removed as well)
    • repeat loop code gen optimized some more

    Once again: the CommanderX16 target targets the upcoming "V39" of the cx16 emulator and roms.
    Programs targeting the cx16 compiled with this new Prog8 version may no longer work on the previous version of the emulator (although if you're not using floating point and bank switching, they will likely still work)

    Detailed change list will be added when this 7.0 version is finalized, which will probably be shortly after the "V39" of the commanderx16 is officially released as well.

    • Like 4
  • Create New...

Important Information

Please review our Terms of Use