Is there a NaN (not a number) value in your format? I'm implementing some simple math routines at the moment, and looking for a return value for sqrtf(x) with x < 0.
Hallo Besucher, der Thread wurde 21k mal aufgerufen und enthält 106 Antworten
letzter Beitrag von daybyter am
gcc-6502 (english thread)
- Claus
- Erledigt
-
-
It seems reasonable to follow IEEE 754:
Zero
Zero is represented with an exponent field of zero and a mantissa field of zero. Depending on the sign bit, it can be a positive zero or a negative zero. Thus, -0 and +0 are distinct values, though they are treated as equal.Infinity
Infinity is represented with an exponent of all 1s and a mantissa of all 0s. Depending on the sign bit, it can be a positive infinity(+¥) or negative infinity (-¥). The infinity is used in case of the saturation on maximum representable number so that the computation could continue.NaN
The value NaN (Not a Number) is used to represent a value that does not represent a real number. They are used in computations that generate undefined results so that with NaN the operations are defined for it to let the computations continue. NaN‘s are represented by a bit pattern with an exponent of all 1s and a non-zero mantissa. There are two categories of NaN: QNaN (Quiet NaN) and SNaN (Signalling NaN).The cool thing is, that the format that puppeh proposes is identical to the CBM float format except for the fourth mantissa byte. So one could easiy apply the ROM routines after filling up the final mantissa byte e.g. with zero.
-
So just define the NaN as bytes and hope, that the proposed representation won't change?
-
I am not sure I understand. I guess setting exponent and mantissa according to IEEE 754 is most efficiently done by simply setting the 4 bytes to predefined values, so yes, this seems the most reasonable way to do it. If the format changes, this obviously would need to be adapted...
-
Trying to run 6502-gcc-ar to create a lib, but I get 'Cannot find plugin 'liblto_plugin.so' , although this lib is installed here?
-
I also ran into this when trying to peek into libs with 6502-gcc-nm . No idea how to solve this...
-
Tried ldconfig to fix the issue, but it seems it looks for a different version of the lib, or so? (but how does the 6502 gcc compile then? ).
I use (0.0/0) for NaN now, which is kinda hack, since it's returned as -NaN , but better than nothing, for now....
Started to ported the 3d program from the cc65 thread to gcc, but so far, it just bails out, when started. Maybe my math functions are broken, or so. Have to look further.
-
This is weird...I move the bitmap screen to 0xc6000. But when I clear the bitmap, the program crashes, although there shouldn't be any code between 0x6000 and 0x7fff ?
I'm confused...
-
A bit further...after a while, I figured that the getMax* function are the actual problem. I wanted to set a function pointer to one of those methods depending on the resolution, but it doesn't work (doing the same for the plot function works, though). My idea is, that gcc just optimizes those small functions away by inlining them, so I added a __attribute__((noinline)) before the methods. Still doesn't work, yet. So I just set the resolution by hand as a quick workaround. Current status attached..
-
Very nice work! And your float routines seem to work nicely. Unfortunately it is pretty slow, do you think that some low level optimizations for the math functions might help?
-
Yeah, there is a _lot_ of room for improvement. My math routines are so slow, because I wanted something, that I can understand easily, so I can debug it. The other problem was, that very optimized math routines are usually optimized for the binary representation of a float. So before we adapt such a method for our format (most of them are for the 754 format, it seems) we should agree that we stick to this format.
The graphics code is also quite slow. We need methods for vertical and horizontal lines as an example. But I was busy debugging code, and I am happy, that the graphics lib now has the in the 2nd 16 kb bank, so we can write bigger programs. 4th bank (under the kernal rom) would be even better, but this requires more modifications (switching the kernal off for bitmap reading etc).
I also looked into the c64dtv 256 color mode. Would be cool for some stuff.
-
Another proposal: we could use those programs as benchmarks, if we had a time() function. We could just init one of the cia timers at program start and write a simple time method, that returns the current system time as seconds.
http://www.tutorialspoint.com/…brary/c_function_time.htm
http://codebase64.org/doku.php?id=base:cia
It won't be the actual epoch time, but since we only need time differences, it wouldn't matter. Then add a drawChar method to display the time and some getch() to pause the app.
A timer resolution of a second should be sufficient for now?
What do you think?
-
Great idea! I wonder, if the clock() function would be even more useful, as it is independent of an epoch and more precise (cycles). That would probably need both timers though, to cover a range that is big enough.
-
-
Ok...somewhat further...
I started a function to draw strings on the bitmap and there are several problems.
The char are stored in screencode order in the character rom, so I had to start a method to convert petscii => screencode. Not complete yet, though.
Another issue is the character rom. I cannot access it directly, because I have to switch the memory mapping before. So I wanted to copy it to ram. Problem: where to put it? Maybe under the basic rom. Tried, but but it didn't work so far. So I just copied it to 0x3000 for now. Just a hack to test the drawing method.
-
Wow, looks nicer and nicer ! Why do you need to copy the character ROM? Why can't you access it from where it is? Obviously you cannot perform certain I/O operations during this time, but is this a problem?
If it is, could you maybe also copy only the char that you actually need at a time instead of the whole charset?
-
I have to disable IRQs while accessing the char rom as an example. But maybe you are right, that just copying the currently drawn char would work.
-
Just started a time module. Not used yet, but take a look at the sources.
-
Ah, certainly! This raises a good question: do we need IRQs at all during C-program execution?
-
What if a program needs keyboard input?
BTW: the libs have to be converted to real 'libs' . We have to get this archive tool going...