amiblitz 2 avoid fpu usage

[tolkien]

I'm coding a little game with amiblitz2 but i would like to know what commands made use of the fpu to can avoid them.
I know is a difficult answer but I'm sure you know a few of them.

Greetings mates.

[Daedalus]

It's hard to tell. The main one I've found is Val() (you can replace it for integer conversions with vallong() ), however other commands may use similar code conditionally. For example, NPrint is mentioned as requiring an FPU, but I haven't had any problems with it myself. Your best bet would be to extensively test any executable in WinUAE to make sure it works without an FPU.

Alternatively, you could also use the latest Blitz 2.1 version, which is guaranteed to be FPU code free (and 68020 code free).

[Anakirob]

Originally Posted by tolkien

I'm coding a little game with amiblitz2 but i would like to know what commands made use of the fpu to can avoid them.

I wrote you a really good answer and my shitty 64-bit PC had to crash when I went to post. So now you get a crappy short answer.

Which AmiBlitz commands need the FPU you ask? Pretty much all of them mate!
And the ones which don't are available in regular old Acid Blitz 2.1!

If the classic Amiga is your target then save yourself a lot of trouble and be sure to use Blitz 2.1 and avoid AmiBlitz. AmiBlitz is really for developing OS3.9 or OS 4 applications.

I know that this is a generalisation, but I'm not typing 1000's of characters to give a decent explanation when Opera could easily take down my entire OS again while I'm half-way through writing the damned thing!

[tolkien]

Thanks mates...well, it seems the easy way is to go to bb2.
I was confortable with ab2 but the use of a fpu is so stupid...
Thanks again!

[Daedalus]

Well, as I said, it's possible to create code that doesn't use the FPU - I do it all the time. However you could also compromise and do your development in AmiBlitz, but the final compile in Blitz 2, which is also what I tend to do. The problem there being you can't take advantage of all the nice AmiBlitz includes without also porting them over to Blitz 2.1, something I'm slowly working on as I need them...

[tolkien]

I'm nor using the includes right now so that is not a problem.
I have tried to compile with bb2 and had a few problems. Need to see what is different. Basicaly, from memory, something like *pointer.bitmap= addr bitmap(bm) give me error. Will look what happends and what are the differences between two blitzs)

Thanks again.

[Daedalus]

Assigning pointers and NewTypes like that should work fine in both versions. However, the definitions are stored in a resident file so perhaps that's the issue? In Blitz 2.1 you need to specify the full path to the resident file, whereas in AmiBlitz you just specify the filename. So it should be Blitzlibs:Bb2objtypes.bb in Blitz 2.1, and just Bb2objtypes.bb or all.res under AmiBlitz. Once that's in place, the same code should work.

[tolkien]

Thanks...just now am reading about that.
Does bb2 have all.res or can one be created?
I'm thinking then to use ab2 and the final executable be done in bb2.

[Daedalus]

BB2 doesn't come with an all.res, but the AmiBlitz one might work with BB2 since it's just precompiled definitions. If not, it's easy enough to make your own by importing the definitions you need, but you probably only need a couple of the separate files anyway, such as the BBObjects and amigalibs ones.

[tolkien]

I have it! Thanks so much. Now I can concentrate in coding

[Cylon]

I think 'optimize...' causes alot of FPU dependencies in the executable. I mostly use BB2 for all below RTG&060+; this seems to work out quite ok.

[tolkien]

Sure Optimize has a party with the fpu!

I have a problem with *pointer.BitMap = Addr BitMap(0)
It works with Amiblitz2 but no with bb2 or ab3. I add all necessary resident files but don´t know what happends.
I will try *pointer.BitMap = Peek.l(Addr BitMap(0)) again

[asrael]

Already a while ago.

But is it not possible to avoid FPU code in resulting executable if 'optimize 2' is not specified?



Manfred

[Daedalus]

No, not entirely. You can avoid certain commands that always use the FPU, but there's always a chance that your code still uses an FPU register or opcode at some point. Best to extensively test your executable afterwards to make sure it works fine without an FPU.