Hello everyone!
I am the author of ugBASIC and I’m really happy that it interests this community!
First of all I confirm that the purpose of the ugBASIC compiler is to generate the most efficient executable possible, mainly in terms of time and then, secondly, in terms of space. However, each 8 bit target has very different characteristics, where the concept of “optimization” could have very different meanings.
As for how it’s implemented, there’s actually no separation between code and library, and there’s no real “runtime”. Code and library are “mixed up” together, on demand. This is especially true if you write procedures that take advantage of multitasking. Obviously, if graphical instructions are used, the system must include everything necessary for relative implementation. Since it is optimized for speed, some information could be precalculated and use a lot of memory, since it is more efficient to read a data than to calculate it on 8 bit processors.
Moreover, regarding the size of the executables, it must be said that (on some targets) these do not change with the complexity of the source code or embedded data. For some of these, such as the Commodore 64 for example, the compiler map as much RAM as possible, disabling ROMs and so on. In this way, when reading the executable, it can take advantage of the standard operating system routines as loaders, thus giving even more space to the user’s code. Think of the PRG as a kind of C=64 memory dump. In other words, the 50KB for C=64 remains the same, almost always.
Finally, regarding the vestigial code, you are right. On some targets I have already introduced support for removal it following the developer’s instructions, through specific DEFINEs. These are optimizations of last resort, which serve to save space when needed. I would extend those techniques also on Commodore 64, as well.
In the coming months I plan to introduce support for read and write access to storage media. This is a really challenging goal because, at the time of the 8 bits, the concept of transversal “standard” on each machine was extravagant, so each one introduced its own (proprietary) way of storing data. Since ugBASIC is an isomorphic language, it will not provide an abstract interface, and thus is even more challenging. I also confirm that the target roadmap will be expanded over time: the project is “open source”, so any contribution is welcome!
Thank you again, and I hope it could be useful for your purpose!
ps. Mr. D’Errico is very right, the generated asm code is verbose, with license duplications. In partial defence, the program output is not meant for code analysis but as input for an assembler, who doesn’t care about the presence of a license in the product code; on the other hand, one of the planned improvements will be to remove all comments except those strictly necessary (as the ones by the IDE). I hope to implement this improvement soon.
