Beiträge von daybyter

Compiling some information on dynamic loading...

http://www.ibm.com/developerwo…rary/l-dynamic-libraries/

So I started the first attempt to create libs. But so far I cannot use 6502-gcc-ar, because I have no clue what commandline options to use. rcs or cr doesn't seems to work. av (the ar65 version) also doesn't work. It seems the wrapper scripts are doing some kinda transformation, that I don't understand yet.

I don't know yet, what to do with the conversion routines. Maybe put them into some mathutil.c File, or so?

I also studied the gcc sources and was reading the real implementation there, using longs, and such. Is that the implementation, that is currently use? I wonder if some 6502 assembly code would perform better. Maybe just start a add( float, float) function and give it a try?

The makeifle could use a install option, but I'm not sure about the directory structure? At the end, it would be cool, if the libs would go into the gcc-6502 distro.

Graphics lib stil to come.

puppeh: do you think it makes sense to add fast double and routines for floats, that just inc or dec the exponent? Some of the math routines need 2*x or 0.5*x , so they might benefit from such routines?

No problem.

BTW: just added the 3-asm-line ieee 754 conversion. Seems it makes no difference when it comes to speed. Still 1867s. But since it should be at least a lot smaller, I'll let the asm version in the sources.

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.

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.

Could we use cc65 tgi concept?

http://www.cc65.org/doc/c64.html#toc5

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.

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.

Der Klassiker für Copro Tests war wohl das Mandelbrot Programm der C't. Das wurde für sehr viele Varianten angepasst.

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.

Der Copro muss mindestens den gleichen Maximaltakt wie die CPU haben.
Schau mal, ob Du einen IIT 80387 findest. Den fand ich besser als den Intel.

Der Weitek unterstützt nur einfache Operationen, ist dafür aber sehr schnell.

Wichtig ist halt, welche Software Du benutzen willst. Diese muss den Copro benutzen. Beim Weitek gibt es wohl nur sehr wenige Programme, die das tun.

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. With

int 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.

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.

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.

Ok, still pulling your sources...but...

I got something working! I rewrote the sqrtf test loop about a bazillion times, until I realized, that the printf was the problem!

When wrote printf( "sqrt of %f is: %f", f, sqrtf(f)); the root was negative and all over the place.
When I wrote 2 printf statements to print f and the root, the result was ok.

So I just copied the sqrt code from the sqrttest line by line into a function and ran the sincos test from there. And now I want to upload it, before I touch it again in any way! It is crap in many ways. The union is missing, the conversion in slow, ugly and complicated. But the result looks reasonable.

Maybe we should add some math code to git, so we have revision control?

Anyway...I am happy for now...

I used puppeh's version (updated in between), since I thought he had your modifications in his version, too? Will start from scratch now with your sources.

The version with a union is in math,c, too. But so far it made no difference from the result. Just the missing warning. Will fix this, once it works.

Acryllack Graubeige RAL 1019

guck mal dort...

Ok, just did the conversion step by step and it seems the shift doesn't work?

i = 0011111000100000000000000000000
i >> 1 = 0000111110010000000000000000000

?

What really astonishes me: the sqrt( 0.15625) is really almost perfect. But it doesn't work for almost any other number...

BTW: I thought literals are translated now to petscii?

Yeah...the ieee conversion fails already...
Just wrote a test program to display the bitpatterns of each number, so I can reproduce this example:

https://en.wikipedia.org/wiki/…are_root#A_worked_example