DZ-Jay Posted July 18, 2021 Share Posted July 18, 2021 (edited) During the past couple of years, I've been helping some very talented people with performance optimizations in their IntyBASIC programs. Mostly, this involves off-boarding procedures onto Assembly Language subroutines. I've also tried to provide "glue code" to integrate some of my existing framework modules (honed down throughout the years with the help of many others), such as the Intellivision Music Tracker and the Pseudo-Random Number Generator libraries. However, in the course of this work, I've come across some limitations in the way that IntyBASIC integrates Assembly Language code, that have made my job much harder than I wish. None of this takes away from the fantastic work that @nanochess has done on the language and the compiler. Indeed, it is an excellent tool with many, many strengths. So the issues I've encountered are not so much shortcomings or drawbacks, but rather pain points at the very edges of its capabilities. I guess you could say that I've been trying to "abuse" instead of "use" the compiler, in ways that I should not. Nonetheless, I present below my humble wish list of features I would like to see added to IntyBASIC in the hope of increasing its versatility and flexibility, and enhancing its integration with lower-level libraries. I admit that I am not really an IntyBASIC programmer, and I do not know to what extent these features would be used by others; but I figured I may as well ask nicely -- and who knows, if they are simple enough, Óscar may implement them. My IntyBASIC Feature Wish List Access to IntyBASIC constants from Assembly Language. This could be as simple as munging the names in the same way as is done for variables, and injecting them into the generated assembly code as symbols. Conditional compilation or logical expression evaluation at compile time. The IntyBASIC compiler performs some internal processing during compilation to decide what additional modules or subroutines to add to the final assembly code, but does not give access to this mechanism. Also, DEF FN user macros perform constant expression evaluation and text substitution at compile time, but logical expressions result in actual generated code (as could be expected). This prevents such macros from conditionally including one out of possibly many specific statement blocks depending on purely constant values given in the IntyBASIC source; similarly to the way that the compiler itself selects, say, what code to generate depending on the arguments of the PRINT statement. Assembly code in user macros. Right now, DEF FN user macros accept any valid IntyBASIC code -- except the ASM directive. I'm sure there are valid reasons for this, but I have found that this one limitation prevents a more natural interface between the IntyBASIC and Assembly boundaries. Specifically, because IntyBASIC does not support a user-accessible pre-processor, one must rely on assembler macros to perform compile/assembly-time processing and conditional code generation. However, doing so makes them automatically off-limits from the IntyBASIC DEF FN construct, which results in a more convoluted or stilted integration. Ideally, I would like to define Assembly Language macros, and then wrap them with IntyBASIC user macros, in order to gain access to the parameter passing and results value mechanisms offered by the compiler. Ability to inject code at the end of the program. I know this may be a bit esoteric, and you may even think it's completely unnecessary, but I entreat you to hear me out. Very rarely, but sometimes, it may be useful to override some functionality of the IntyBASIC framework encoded within the "intybasic_epilogue.asm" file. Of course, this could be done by hacking the epilogue module itself, but then each project would require its own copy of it, and sharing common code across programmers would require them to be aware of such caveat, etc. One alternative to this -- which I've employed in the past on assembly language programs -- is to add a patch at the very end of the code, which re-points the program counter and interjects with replacement code. Obviously such a mechanism is not to be used lightly, but in my experience it has proven to be very useful. However, because the IntyBASIC compiler always follows the user's program code with the epilogue module, this is not possible. Perhaps some sort of special marker could be included that states "add the following at the very end." Global access to fully-qualified local labels. This is another advanced feature, but I think it will prove very useful. Right now you can define local labels with a "." prefix, but these are private to their respective parent label. This limits their practicality and utility. It would be better if we could access the local labels by fully qualifying them. For example: ' Table of level parameters LevelData: .L1: Data 1, 1, 1, 1 .L2: Data 2, 2, 2, 2 .L3: Data 3, 3, 3, 3 ' ... ' Get a pointer to a specific level table #LevelParams = VarPtr LevelData.L2 This puts the compiler usage of local labels in line with how the assembler treats them. The way it works right now, you have to specify individual global labels for each sub-table, even though they are all related -- or worse, you will have to use pointer arithmetic to compute individual sub-table pointers by keeping track of the size of each table. Access to local labels using fully-qualified names offers the best of both worlds: Ability to have local labels, and the ability to keep the scope of your related labels constrained. Support for function macros in constant definitions. Function macros ("DEF FN") that evaluate to a constant expression should be legal as "CONST" values. Right now, the compiler rejects anything that is not a literal constant expression, a literal value, or another constant. That's it for now. I hope that @nanochess at least considers these suggestions. And if there are better ways to accomplish some of them, then I'd be very happy to learn them. -dZ. Edited July 10, 2022 by DZ-Jay 2 Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.