Weird. SiN WarpOS had sound?

At least the version I had. Welcome back Steffen.

Never heard of e400, but indeed, it seems that for example the PPC400 is a bit picky. Still, I think this is not an alignment problem.

@kas1e

Had a look and it indeed applies only to FPU access. Integers can be accessed any way you like.

@kas1e

WOS: yes
ReWarp: yes (revealed a bug in ExecSG actually as Shogo was drawn incorrecly, which was an error in the alignment exception handler for fpu registers)
WOSEmu: I think so.

Why?

lzwu 0(rx) does not work as you think it does maybe. It should be lzw 0(rx) as lwzu is post-incrementing the rx with the offset; in this case 0 so nothing happens.

And stack is normally restored by lwz r1,0(r1).

This doesn't help you with your crash. I'll have a look at your source.

EDIT: Apparently I replied to an old posting..

Educated guess:

r11 is loaded from the address made from r9+r10. r10 is a byte value (seeing rlwinm) and r9 is also not an address (alpha) which gives some undefined address. I am guessing you are getting a DSI error?

Which is the same as addi r3,r2,_BlankChunky-DataStart

You cannot address a memory location like that as the operands are 16 bits. That is why you need 2 lines to load an address. la is used with a 16 bit offset. So you load for example r2 with a 32 bit address with the macro (let's say DataStart). Then you use
16 bit offsets to this pointer with la as in la r3,_BlankChunky-DataStart(r2)

I think la is indeed used differently on vasm. it is 'la register1, offset(register2)'. You could use that with r2 (TOC) as being register2 for example.

but for the la used in PowerASM you could use something like

Well, you say you don't want to use an argument....so remove the __ARGS and replace it with a number (stack size).

However! :

My macros can be used without arguments too. It will then default to 1024 stack size.

So it either takes 0, 1 or 2 arguments. The arguments being TOC (also place r2 on the stack) and stack size.



And:



This worked last time I checked. In the past various VASM versions would error on generic arguments like \1 and \2. Haven't tested these in a while.

The 56 or 60 is for room for the volatile registers r3-r12 and some more stuff.

I see in your example lr is saved to 20(r1) but maybe that is SysV ABI which is quite different from the one used in WarpOS.

Is there anything in particular you want to ask? I happen to have (part of) the WOS/68K WO2097 source (which I obviously cannot share).

I think it is a license problem that it is not out for OS4, same with SiN (which works quite nice on my PPC card).

wosdb uses WarpOS ppc exception handlers that are not(/cannot be ?) implemented as part of the warpos emulation on OS4. It is low-level kernel stuff.

Personally, I use vdappc as a disassembler, but it does not recognize hunks or text.

As for the push/pop stuff, the easiest is just to make a macro that pushes and pulls r14-r31 to r13.

Bloats your code.

ReWarp uses a form of prolog and epilog.

Also the WarpOS ABI describes r13 as being for local stack and not r1. The original prolog and epilog macros do exactly that (setting up r13).

Edit: nvm. I somehow thought r1 was used but you use r13 correctly.

Edit2: I see I left out the TOC argument in the ReWarp macros, but the sonnet library macros are more complete. You can look there for inspiration.

So when is NovaBridge coming?

@BSzili

See http://eab.abime.net/showpost.php?p=1516043&postcount=4869

Just see it as a rule that any unaligned FPU access is problematic.

Seeing the various code snippets, isn't the one with the lwz asm faster or is your/corto's code optimized to lwbrx?

Yes, normally with packed structures you would put all floats at the top. But here the input is already fixed. So the float is actually at offset 1 in that binary data. So in memory the loaded data will always have the float at offset 1. And of course, in this cause you might load the data in at offset 3 so the u8 flag will be at offset 3 and then the float at offset 4 (and add 3 dummy bytes at the start of the struct, and allocate a slightly bigger buffer) but then other loaders would give errors probably.

So going the integer way and then convert should do the trick. I am not sure why it is still crashing when you do that. I then need to see the asm output for each case.

That loader you show has everything aligned. That is why it does not crash. The floats are at the top so start at 0. The other struct has a u8 at the top so the first float starts at 1 (and therefore is misaligned for the PPC FPU).

Loading it as an integer and then convert it to float should work (the examples by salass and corto). You said they also crashed but i'd like to see also the GR output there. I am suspecting it is a different alignment issue (not FPU).

Ok, Now i've re-read everything...

The data presented is a binary block? So everything is fixed already? And the struct is a representation of this binary block?

So salass is more right towards the solution (sorry).

You should try it again and see if the GR is different regarding the asm.

In the quick reads I did I think I read for example that lwbrx also gives an alignment error on byte aligned addresses. So maybe with his suggestions you got a different alignment exception.

You could do two things

1) Put the floats at the start of the struct
2) Make it 4 (but that is actually the default so removing it might be better. 2 will still give alignment trouble for fpu.

Why is pragma pack(1) needed?