Hi daybyter, great work! Yes, please go ahead and upload your work to the git fork, that is what it is for! As it is only an "unofficial" fork, I think it is totally fine to commit untested or unoptimized code to it.
Hallo Besucher, der Thread wurde 21k mal aufgerufen und enthält 106 Antworten
letzter Beitrag von daybyter am
gcc-6502 (english thread)
- Claus
- Erledigt
-
-
BTW: the sqrt results are not very precise (but good enough for the graphics stuff). Maybe we should add another (optional) iteration. Some precision flag (maybe a define in the math lib) would be nice. So you can chose between fast and precise.
-
In theory yeah, use the IEEE754 representation for NaN & infinity, adjusted for the new field positions. In practice the existing arithmetic routines don't support them directly IIRC (but that's probably a bug that should be fixed).
-
Looks like awesome work on the maths routines! Are those something I can pull into libtinyc?
With regard to zero-page variables, there is an address-space modifier "__zp" that can be used to declare variables in zero page:
__zp int c;
but it's very buggy (it did work a little better at some point). In theory you should be able to declare such things as zero-page pointers to normal RAM:
char *__zp myptr;
or even arrays, I think like:
char *__zp[4] myarr;
myarr[idx] might then use the (absolute,X) addressing mode -- but, you'll probably just get compiler crashes if you try that at the moment!
-
Well, I have to work on the cbm <=> ieee conversion to make things a lot faster.
It would be cool, if the math code would end up in the gcc distribution, but wouldn't it be better in a separate math lib? (other than libtiny, I mean.) When I played with the math routines, I sometimes just renamed methods, but I quickly ran out of ram, because it seems all the methods were linked to the prg, even if I did not call them? So the math routines in libtiny would bloat programs, even if the user doesn't use fp math, then?
I have to look into this further, though.
-
Wanted to take a little slacking cut from the math stuff (will continue to hack the ieee conversion tomorrow, so I can learn extended asm), so I just fixed the weird pointer casting, but then took a close look at the graph drawing algorithm, reversed the y direction and added an array for a horizon line.
Had some weird problems. Withint XRes = 320;
unsigned char horizon[XRes];
..init code..., the emulator crashed. With
unsigned char horizon[320];
...it works...
Anyway..another nice speedup again...but it will only work if the graph is drawn from bottom to top...
BTW: I have to work on the graflib again. The bitmap buffer has to go to the 3rd bank, so programs can get bigger.
-
it seems all the methods were linked to the prg, even if I did not call them
Daybyter: I think the linker can only strip out unused object files. So if all functions have been in the same source file math.c, this is expected behavior. To make it more memory efficient, every API function should be placed in a separate source file.
-
Yeah, my idea was to put the math code into a lib/math/ directory once the archive tool works and we can create an actual lib file. Same goes for the graphics stuff.
BTW: is there a way to load code at runtime? Would be nice to load only the graphics driver for the used resolution. Would make the code somewhat smaller, if only the hires code or multicolor code is in ram, but not both.
-
BTW: is there a way to load code at runtime? Would be nice to load only the graphics driver for the used resolution. Would make the code somewhat smaller, if only the hires code or multicolor code is in ram, but not both.
I think this is rather complicated to do in C. IMO this should be rather solved on API level, meaning that there should be separate functions to handle MC and Hires. This allows the right code to be selected already at link time. When browsing the web for small libc implementations I found interesting discussions on how an API should look like for size optimization. The result was mostly, that API's that allow very different code to be triggered by a runtime argument are BAD . The most prominent example being printf, which can trigger all kind of different code depending on the string that is passed. A good/modern API would split these functionalities up (print a string, convert a float number to a string, etc.).
-
I already started to split the graphics code into methods, using function pointers. But this was mainly for speedup. I wanted to avoid the if(graphicmode == hires) { ... in the plot/line/... methods.
-
Unfortunately the linker cannot understand, how the pointer will be set during runtime. Do you see reasons against having something like:
entergraphicsmodemc()
plotmc(x, y)
linemc(...)entergraphicsmodehires()
plothires(x, y)
linehires(...)Obviously the API gets larger, but the program itself can then clearly signal to the linker, which functions are needed and which not.
-
Well, the idea is, to write code, that does _not_ depend on the graphics mode! Imagine code, that should also run on c64dtv, or even atari and such. See borlands bgi or cc65 tgi concept.
-
Ok, makes sense. But it seems to me that a portable API and small code size exclude each other to a certain extent in this case.
-
-
It's kind-of possible to do run-time loading using a dispatch table: I did that (not really recommending doing it precisely that way!) in https://github.com/crtc-demos/…blob/master/disco/disco.c.
-
Thanks for the hint! That might be a step towards the solution.
I just looked after the 6502-gcc-ar problem with liblto.
strace ./6502-gcc-ar | grep liblto
, is showing the problem:
stat("/usr/src/gcc-6502.claus/gcc-6502-bits/prefix/libexec/gcc/6502/6.0.0/liblto_plugin.so", 0x7fff03633630) = -1 ENOENT (No such file or directory)
So I symlinked my installed liblto to that directory:
ln -s /usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so ../libexec/gcc/6502/6.0.0/
(I was in the prefix/bin directory that moment).
Now the gcc-ar tool starts and returns
./6502-gcc-ar: Cannot find binary '6502-ar'
Running a
updatedb
followed by
locate 6502-ar
, showed, that 6502-ar is in gcc-6502-bits/wrappers/
So I went to /usr/local/bin and did a ln -s <wrappers dir>/* .
Now the ar tool seems to work. At least it starts and shows some info on it's commands.
-
Sorry about the config problems! I'm a bit confused though, because 6502-ar is just a shell-script wrapper for the "ar65" tool supplied with cc65. (Generally libraries won't be compatible with cc65 because 6502-gcc is using a different calling convention.)
Perhaps rebuilding cc65 might help if you maybe have an out-of-date binary installed? Just guessing.
-
Ah, I also have 6502-gcc-ar, and it doesn't work for me for exactly the same reason! I think you can just ignore that one.
-
It seems the wrapper scripts are not found. So I think it's rather a 6502-gcc config issue. I just use some cc65 distro for debian. Did not compile it by myself.
-
Checking again, basically the only library I've built is libtinyc -- and the compile.sh script for that just calls ar65 directly. So I guess that's the easiest option!
Apologies again for the trouble, I should really have written some decent documentation at some point...