(50G) [HPGCC3] DRAW3DMATRIX replacement with grayscale surfaces, proof of concept

[3298]

You posted while I was typing this essay ... looks like the "band-aid solution" below is what will fix your problem. However, installing the other patch is probably a good idea too, at least if you plan to use 64-bit values in your programs. The rest is probably less relevant for you, but I wanted to keep this explanation as generic as possible.

Most of what I write is supposed to be changes to the procedure Claudio has described in his HPGCC3 installation tutorial. Note that even though he recommends Ubuntu, it'll work on many other distros as well. I'm using Manjaro, for instance.
The first change is about Eclipse. You don't need to install it because that'll just give you a version that doesn't like HPGCC3's plugin. (At least, that's what happened for me.) I downloaded and extracted Eclipse Indigo (select the C/C++ edition, and either Linux x86 or Linux x64 depending on what kind of Linux you installed) to my home folder. Starting works from the file browser (start the file "eclipse" within the extracted folder) instead of the system's menu, but whatever. You probably know those procedures from OSX or Windows already.

The second change is a source code patch for the tools. You need to apply it before building tools_workspace. It works like this: download the attached file tools_patch.txt (it appears this forum doesn't allow me to use the proper file extension, which would be .diff or .patch) to the tools_workspace folder, open a terminal and navigate to that folder, then run this command:

Code:

patch -p1 -i tools_patch.txt

What this patch does is some changes to the code that turns the compiler's output (in ELF format) into raw binary files. At some point there has been a change in GCC regarding alignment which the code couldn't handle. This caused the data section in my programs to sometimes be shifted by four bytes, which made all things go haywire. This patch repairs that by making the alignment code less picky. (I don't know if the change to elf2rom is necessary, but just in case... The elf2armc thing fixed my alignment problem though, so it is actually needed.)

My next note is more of an addendum regarding C program development instead of an extra build step. It's also not a proper fix but rather a band-aid solution.
Basically, I noticed that the ROM code is supposed to have only a few variables (which it sticks into a section called romglobals; this is then compiled into every HPGCC3 program you write). But it has a few more variables which overlap with your program's. When these variables are used, they may lead to bad stuff if the HPGCC3 libraries read them, or to other bad stuff later when they write to them, thereby trashing your own variables.
My workaround is to put this somewhere into my code (main.c seems like a nice enough place for it):

Code:

/* workaround for ROM globals placed at the start of the .data / .bss area; we need to shift out own variables past them */
__attribute__((section(".romglobals"))) int __ROMglobals__[20]={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

Technically the comment is useless, but I like to keep it because it reminds me why this weird line is there. It also explains how this fixes things: it enlarges the romglobals section to cover these undeclared variables as well, so the linker stops putting our own stuff there.
For my ROM 80 bytes were clobbered by the undeclared variables, which is why this workaround is an array of 20 ints (with an additional compilation option disabling a certain optimization it increased to 84 bytes, see below at the mfctop description). If you want to check how many bytes are used by your own ROM, do an objdump of libs_workspace/romlib/__romlib.exe and look at the .data and .bss sections.
Some of these ROM variables are written before they are read, or they are supposed to be zero-initialized. Unfortunately that's not always the case. I didn't account for those variables because 1. I don't use the functions that need them (i.e. I don't care enough), and 2. the compiler someone else used for their ROM may have put the variables in a different order than my compiler (not really fixable).

These ROM library variables could be fixed properly, but I didn't do that because I wanted my program to be able to just work on other people's ROMs which weren't likely to be fixed, so I opted to use the workaround in the program this thread is about.
The variables I identified are:
- uarrone from libs_workspace/decnumber/common/decNumber.c, not zero-initialized; theoretically fixable by declaring it const, but the decNumber library is strictly not-HP-specific 3rd-party code, so I didn't want to tamper with it,
- mfctop from libs_workspace/decnumber/common/decCentext.c, not zero-initialized; also theoretically fixable by declaring it const (resulting in a weird "const * const" declaration), or by removing it and changing the only use (the LITEND macro on the next line) to refer directly to mfcone instead of dereferencing mfctop; this one apparently gets optimized away when compiling the ROM with normal options, but when Claudio instructed me to try adding -fno-toplevel-reorder while troubleshooting this issue it showed up,
- qcompar from libs_workspace/hplib/sys/qsort.c, written before first read; could be removed by rewriting qsort and its recursive helper function qsort1 to pass down qsort's parameter compar instead of relying on a global variable,
- indicator_hpg from libs_workspace/hpg/common/hpg_set_indicator.c, written before first read; should be fixable by turning it from a static local variable into an ordinary local variable, because the "static" semantics seem to be unnecessary in that place.
- gglorgaddr from libs_workspace/ggl/ggl/ggl_initscr.c, written before first read (at least if you use it as designed, i.e. ggl_initscr at startup and ggl_freescr at exit); this is the nastiest one not only because it's in an important function (if you plan to use GGL for your graphics at least, like I do - this is why I discovered this issue at all: this variable overwrote one of mine), but also because it's the hardest to get rid of the proper way. I think it should end up in the master globals or system globals table.

On another note, even though HPGCC3 appears to be designed for Eclipse, it's quite possible to build stuff without using that IDE. Once a project is generated using Eclipse, the code can be written in any editor, while using "make all" in a terminal for compilation. Adding, moving, or deleting files (or any similar changes to the project's structure) is probably still easier via Eclipse, but maintaining the project files (.project, .cproject, Debug/*.mk, Release/*.mk) manually is quite possible. The first two could even be dropped, and if one build configuration is enough the other one could be deleted as well. I use Kate, I edit the project files manually, and I've not yet had an issue due to that.