<Omikron Basic> "COMPILER 68020"

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Omikronman
Atari Super Hero
Atari Super Hero
Posts: 525
Joined: Wed Dec 01, 2004 12:13 am
Location: Germany
Contact:

<Omikron Basic> "COMPILER 68020"

Postby Omikronman » Tue Jan 08, 2013 4:11 pm

Hello,

the manual to the Omikron.Compiler 3.5 does not tell much about the compiler statement "COMPILER 68020". It suggests some improvements on the code for usage with a CPU >= 68020. Given a try on my Falcon there was surprisingly a speed-decrease when compiled with the 68020 statement. So what exactly does it do and where should things become better with it?

Tnx :-)

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: <Omikron Basic> "COMPILER 68020"

Postby dml » Tue Jan 08, 2013 4:54 pm

I don't know this compiler but here is my guess.

Selecting a CPU type in any kind of compiler results in a bunch of assumptions about the machine - some of which will be wrong. On the Falcon the biggest 'wrong assumption' would be a 32bit data bus - the compiler may start rendering code in terms of 32bit longs instead of 16bit shorts, expecting alignment-oriented gains and instead getting a horrible slowdown. You could probably test this scenario by running the same comparison on a TT (or any 030 board with local fastram).

The 68030 also behaves differently from the 68020 - it has a data cache, and this can occasionally get in the way if abused - particularly on the Falcon's data bus (the data cache really doesn't like that 16bit wide fetching!). Harder to differentiate this one but could be tested vs a TT with cache on/off and compare the ratios...

And then there's the compiler itself - it may assume using 020+ addressing modes and bitfield ops (etc.) are faster than simpler 68000 ops, but this often isn't the case either (This part is at least machine-independent so it should be possible to get that right most of the time). Can only differentiate this one as 'whatever remains' from the other tests, if possible at all.

In summary, CPU optimizations sometimes aren't :-) They can and should be, but I've seen some of the best compilers get that stuff wrong on a regular basis. I wouldn't be surprised if Omikron Basic has similar problems.

Even if you identify what the problem is, I doubt you can do much to control it except turn the 68020 flag on or off :)

The main value with 020+ compile modes is hardware floating point since 881'2 ops only interface directly with 020+ upwards.

User avatar
Omikronman
Atari Super Hero
Atari Super Hero
Posts: 525
Joined: Wed Dec 01, 2004 12:13 am
Location: Germany
Contact:

Re: <Omikron Basic> "COMPILER 68020"

Postby Omikronman » Tue Jan 08, 2013 6:57 pm

Tnx for the quick reply ^^. Well, with the Afterburnber040 my Falcon should be a 32 bit computer. Omikron.Basic also supports a seperate compiler statement "FPU2" for use of a 68881/2 fpu, but the 68020 statement can be set seperately of that. The only big difference I see when using the 68020 command is that the compiler makes a .prg that is - of course - not able to run on a 68000 (bombs away if I try to start it).

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: <Omikron Basic> "COMPILER 68020"

Postby dml » Tue Jan 08, 2013 7:19 pm

Omikronman wrote:Tnx for the quick reply ^^. Well, with the Afterburnber040 my Falcon should be a 32 bit computer. Omikron.Basic also supports a seperate compiler statement "FPU2" for use of a 68881/2 fpu, but the 68020 statement can be set seperately of that. The only big difference I see when using the 68020 command is that the compiler makes a .prg that is - of course - not able to run on a 68000 (bombs away if I try to start it).


Ah... it won't be a Falcon thing then, assuming your code is in FastRAM. However the 68040 does behave quite differently from 68020/30 in terms of instruction performance. Optimizations for 020/030 don't necessarily help on 040 and can make things worse. The 040 is also more sensitive to data alignment than 020/030.

So the 68020 switch is probably good for 020/030 but not beyond. It's not particularly easy to generate code that suits all of the newer chips with one switch. 060 behaves a bit differently again!

There are some examples of differences at the link below - although it only scratches the surface...

[ASSEMBLY LEVEL OPTIMIZATIONS]
http://tict.ticalc.org/docs/68k_optimize.txt


Social Media

     

Return to “Other BASIC”

Who is online

Users browsing this forum: No registered users and 1 guest