A.D.A. Amiga Demoscene Archive

thanks Zeroblue . I'll check it out once I'm not progressing on this method. I've come some way now and the final hurdle (I hope) is now linking..

I currently get : Reference to undefined symbol ___builtin_printf.
and a lot of other stdlib functions.

LIBDIR := C:\VBCC\targets\m68k-amigaos\lib

vlink -bamigahunk -Bstatic -Cvbcc -L"$(LIBDIR)" -s -o $(PRG) "$(LIBDIR)\startup.o" -lm040 -lamiga -lvc $(OBJ)

I link exactly like when I build on Amiga so don't know what is different. I've seen this before too, but can't remember what the solution was.

Building in windows and linking in UAE produced the same problem so I'm guessing it is the compile stage which generates references to a ___builtin_printf. These functions don't seem to be in any of the libraries in the VBCC/targets/m68k-amigaos/lib dir. So why are these generated instead of just normal _printf or _memcpy references?

Hmm good one...
I call vlink with got one more parameter that is: -nostdlib
Doubt it could be it, but worth trying :)

But i only configured the default parameters that is, inside my vc.cfg that is used by vc.exe (cross-compiled for native windows using visual sutdio). You can grab my exes and config files if you want to give it a try, there's at the bottom of
http://sites.google.com/site/davidpotages/code-rep ository/winamigasettingupacasmcrosscompilerforclas sicamiga

The error was that I had some stray includes which were not meant for VBCC and that was the origin of the __builtin thingies. Now I have everything compiling and I can run the exe. However it crashes somewhere in the startup of the demo now. Haven't done any debugging. I hope it is something trivial.

The exe I had was crashing because functions like strlen and memset were not working. I got strlen( "data/sw40yo-1.rmsh" ) = 0 for example. So something is very wrong. Re-implementing strlen made stuff work, but of course it seems like most stdlib functions are broken (although printf works).

I'll try Kufas approach now.

The exe I had was crashing because functions like strlen and memset were not working. I got strlen( "data/sw40yo-1.rmsh" ) = 0 for example. So something is very wrong. Re-implementing strlen and memset made stuff work, but of course it seems like most stdlib functions are broken (although printf works).

So I have been messing about for a few hours now, but no luck getting it to work properly.

I'll try your approach now Kufa. I hope that will work better.

Omg. just fetching the sources and compiling all the tools did the trick. Didn't do the nmake changes though, but I'm happy!!

Wohoo good that it works now! Very weird stuff you had, indeed..
Damn i so wish there was c++ support in vbcc!

Now I've got dependency generation from gcc too under cygwin. so my original mission is complete. Now I'm trying out vprof, but it seems to be out of date compared to the mon.out from the exe so I'm trying to fix it with some help from the vbcc guys.

c++ would be great! but not exactly a minor task ;)

We also contacted Phoenix regarding the profiler while developing our last demo. He supplied us with a fixed version of vprof that understood the more recent mon.out format. But unfortunately we still had problems with the timer of the profiler as some seemingly random functions were always assigned negative values in mon.out, which rendered the profiler useless for us (you could not tell where time was spent). So maybe, while you are at it with the vbcc guys, look out for that bug as well.

@loady: haha yeah, c++ is definitely not a minor task =) But hey, the challenge should motivate them :)
Good luck with gprof that is! But if i remember properly, there's some endianess issues too, right? I usually prefer to have my own function profiler that is.

It actually would be great if the targets\m68k-amigaos files would be opensource as well, so that we can hack them around too. (or did i miss a link somewhere?)

the last issue was just endianness (I built vprof for windows and ran it there).. when moving it to the real amiga everything worked fine.. the output listed the polygon sort taking as much time as the polygon fill which was pretty surprising (qsort). made a new sorter which gained me another 6 fps in a worst case moment of chips don,t lie so that was quite cool.