Nekoniaow

I would not say dead end, it is useful as is as long as no performance is expected and has been used for the backbone of many a Oric demo for the past two decades. Only if one wants to try to get as much performance as possible out of a C program would I recommend to not use it. The fact that this happens to be my use case is just a coincidence. I see that the sources have not changed for the last 11 months, is there is still ongoing work on it and/or plans to improve it? I am willing to invest a bit of time into it (a few hours per week) if that can be useful. Edit: 11 months, not years.

Hi everyone. Funny that you mention lcc65. I just stumbled on this thread today while looking for an alternative to it on the Oric (for which I currently code a small demo effect). Lcc65's output is pretty much what one can call a complete disaster in its current state and the amount of redundant, wasted operations it does is quite impressive. A working peephole optimizer could probably remove some of the waste but as of now lcc65's is not compiling. Others in the Oric community have been using cc65 and it seems to generate much better code (even if imperfect, obviously). cc65 and lcc65 seem to rely on a similar technique but do reserve one of the registers for indexing purposes (if I remember correctly) which leads to some glaring inefficiencies when register pressure is high and one would benefit from all available registers. So I would expect that gcc would generate much better code than these. Ideally, it would be nice if gcc was able to select an appropriate calling convention depending on when/how the function is used (in a tight loop, only once, etc.) to provide optimal performance but I doubt it is capable of such thing. A compromise would be to use gcc's attribute system to override the default calling convention and replace it with dedicated ones (register based, memory based) when more appropriate. I am not sure if it does support changing the calling convention on the fly though, so this is quite speculative as well. A more realistic and practical aim though would be to use inline assembly to pass parameters as users desire, C++ templates can probably be leveraged to make this boilerplate-free. Edit: removed some leftover from an uncontrolled copy/paste and added last line.

Thank you for creating this topic, I was also looking for a high level language in order to do a few tech tests of the machines I acquired recently without having to delve into assembly. FastBasic looks really nice, a cursory read of the manual reminds me a bit of GFA Basic for the ST/Amiga. It does not look like it has support for Display List creation so I am wondering if there are equivalent of STOS and AMOS on the Atari 8 bit with integrated support for low-level features such as Display Lists and Sprites (players + missiles)? In any case, I will give FastBasic and MadPascal a try after I get a chance to unpack my machines. Thanks for the advice!