The

# if (__GNUC__ > 4 ) || ((__GNUC__ == 4 ) && (__GNUC_MINOR__ >= 7))
# pragma pack( push, packing )
# pragma pack( 1 )

Tells me that the structs will be byte aligned. Which is not a good idea for PPC.

lfs means load fpu single (so float32) from 0(r31) which is 0x620166D9 which means on a single byte aligned address.

I cannot see if that is due to the struct you showed with the u8 at the start.

Are you btw sure OS4 has nothing? I seem to remember asking one of the Frieden brothers to fix an alignment issue of Shogo_WOS while running in WOS emulation on the SAM440. The fix was done inside the alignment exception handler.

Normally, the compiler takes care of this. So the WarpOS autocorrect should only kick in by old and misbehaving apps. you would move the data using general purpose registers and then load them into the correct fp register. Yes. it is slow.

For more info you could look at the GR more carefully and look at the asm output to see if it is

1) integer or floating point
2) which address it is trying to access (and see its alignment)

Ok, the text in 8.8.6 and 5.1.2 of below document is a little bit different.

https://www.nxp.com/files-static/32bit/doc/ref_manual/EREF_RM.pdf

Ok, the WarpOS kernel had auto correct.

Anyway, the most common alignment errors are:

• The operand of a floating-point load or store instruction is not word-aligned.
• The operand of an integer double-word load or store instruction is not word-aligned.

But like I said, there are exceptions (like the 440) where it is even more strict (64 bit or even 128 bit).

As far as I know integer single word load or store can be done from 1 byte aligned addresses.

It even becomes more murky if for example the 440 has a double FPU attached. Then it must be on a 16 byte boundary i read.

Access with floating point registers to memory need to be either on a 4 byte boundary in the early PPC models and maybe even on an 8 byte boundary for 440 fpu/apu if I remember correctly.

Normally the kernel has code built-in to handle these exceptions, I thought.

Edit:

From the IBM docs:

On the PPC440, any floating point load or store whose
operands cross a cache line boundary (32 bytes) will take an alignment trap. Normally floating point operands are aligned on an 8 byte boundary, so no alignment trap will
occur using a single floating point load or store.

I think the G3/G4 CPUs are less strict.

Btw I thought that a 4 byte alignment for each struct member was default. I am not sure on which PPC you are coding on.

It completely compiled now. Latest msys32 uses gcc 7.3.

Lazy as I was I copied your test.c program to test. It has a typo and is missing a \ most likely.

But it works now! Great!

Oh and that native-build/gcc-cross-build-8.2.0 directory only appears after compiling.

It's builds a lot further now while using 32. The noob in me says the difference in the declaration of void between the two is a problem (64 = size 8, 32 = size 4 I seem to see).

@kas1e

Also gild checkout does not apply patches first time invoked. I double checked now.

Edit: after setting name and email it worked........

@kas1e

I indeed probably forgot the gild checkout binutils step after the long clone step.
Being smart and copying what you did in gcc-build to binutils-build (adjusting the path) made the binutils build error. So that's also my fault.

The last error is weird. I am guessing some 64/32bit error and trying it all again with 686 instead of x64.

Edit: ok this time I am sure. binutils/gcc patches were again not applied the first time I did gild checkout

I guess the patches were not applied? Have to do that manually?

Edit: Doing gild checkout binutils 2.23.2 again fixed it somehow. Must binutils-build makefile also be adjusted for installation path just like gcc-build?

Edit2: And now it craps out on some multiple pattern error in a makefile.

Edit3: deleted all, redid all...and guess what...




I am going to cry myself to sleep now.

Great guide!

Two things:

1) It was unclear to me from which directory to do the make -C native-build (adtools)
2) I don't have a file called /amiga/adtools/native-build/gcc-cross-build-8.2.0/gcc/gcc-vers.texi.

There is no /amiga/adtools/native-build/gcc-cross-build-8.2.0/ dir. Not sure what I did wrong?


Oh and now it errors with BFD does not support target powerpc-unknown-amigaos

@Hedeon

With a new PPC card with a 450MHz G4 and 256MB RAM and a bridge which seems to communicate faster with the mediator I get now the following:


Amiga 3000 Voodoo3 WarpOS 450 MHz G4.

GPmark improved, version: 2018 January 12
Surface dimensions: 640 * 480
Surface is located in RAM
Surface must be locked: false
Display mode: fullscreen
Blitting Test: 134.3
Plasma: 80.0
Rotozoomer: 95.1
Rotozoomer Near: 99.4
Rotozoomer Far: 84.8
Radial Blur: 21.7
3D Bunny: 12.3

Put the WarpOS compiled version up on Aminet.

Amiga 3000 Voodoo3 WarpOS 500 MHz G3.

(I had to test it The textures were wrong regarding edianess, but it should't affect speed)


GPmark improved, version: 2018 January 12
Surface dimensions: 640 * 480
Surface is located in RAM
Surface must be locked: false
Display mode: fullscreen
Blitting Test: 36.8
Plasma: 32.8
Rotozoomer: 33.1
Rotozoomer Near: 33.6
Rotozoomer Far: 31.7
Radial Blur: 9.9
3D Bunny: 5.1

@utri007

What machine?

A program with an internal soft 3d engine like QuakeWOS is actually quite fast. Maybe something can be done regarding wazp3d settings.

I'm planning to replace one by one the different Warp3D functions with wazp3d functions to see what works and what doesn't. If I find the time. In the mean time more and more gets ported to OS4 native so I'm not sure about effort versus benefit.

@kas1e

The artifact problem is current Warp3D compatibility with V4 where all the stuff you tested ran at in the WarpOS days. Not Wazp3D not ReWarp and not warp3dppc.

The slowness of Wazp3D I cannot comment on.

So for the moment I AM interested in a list of WarpOS programs that don't run, but not programs which run on WarpOS+Warp3D.

The patchall environment only helps for the Radeon R100/R200 cards probably.

@kas1e

Warp3DPPC redirects to Warp3D
Wazp3D does not redirect. You rename it to Warp3D in place of the HW renderer.

Then Warp3DPPC in affect redirects to Wazp3D (and then stuff works, albeit slow).