WarpOS/PowerOpenABI vs OS4/ System V.4 ABI problems

@kas1e

Are you using mixed PPC asm and C code? In that case you may have to use the GCC arguments to use the PowerOpenAPI (WarpOS) instead of the (default) SysV one used by AmigaOS 4.x for the C parts. Or change the asm parts from PowerOpen to SysV.
I'd be very surprised if current AmigaOS 4.x GCC ports still support the PowerOpenAPI used by WarpOS at all, but the old GCC 2.9.x versions did support both APIs.
VBCC probably still supports both APIs as well if you don't want to use an ancient GCC version.

@Hedeon
Quote:In my powerpc.library WarpOS emulation it should be implemented, but that was only possible because I had access to both of the ExecNG as well as the WarpOS sources.

@joerg
Quote:

Yesh, compile C objects via GCC , and assembler ones via vasmppc_mot (as this one have the same syntax almost 1:1 as have PowerASM back in past, on which those assembler parts are based).

Quote:

Yes, that what i do (check plz 2 latest posts from me with my_macros.i for sysv, and question about function whhich while looks ok in terms of sysv , but still crashes by some reassons)

Quote:

Nah, i of course don't want any old PowerABI, i even don't want any assembler as it make no sense anymore on any NG machine, but as soures were already written not by me, and i only adapt them to make os4 native version, i had to use them.

@kas1e
Quote:Sorry, I don't understand PPC asm at all, I'd have to look up every instruction in a manual.
For example my powerpc.library is nearly 100% C code, with very few __asm__(inline) instructions added, unlike the newer versions which seem to be 100% PPC asm code instead.

@kas1e

_BlankChunky:
lis 26,_BlankChunky@ha # load the address of the label
addi r26,26,_BlankChunky@l # in r26 (2 steps)


whitout use of mnemonics try these two couple of commands, maybe on your assembler you have to remove the '%' or '%r' registers prefix, under GCC instead I use this.

addis %r26,0,_BlankChunky@ha
addi %r26,%r26,_BlankChunky@l

*************************************

ADDIS - Add Immediate Shifted

Syntax: addis rD,rA,SIMM

This command is used to add a 16-bit immediate value to the upper 16 bits of a 32bit register. It adds a 16-bit signed integer (SIMM) to register rA, then shifts left register rA by 16 bits and then puts the result into the register rD (destination). The lower 16 bits are cleared by this command. So to fill a 32 bit register with an immediate 32-bit value you first have to use addis to fill the upper 16 bits and then addi to fill the lower 16 bits. Otherwise the lower 16 bits would be cleared again by the addis command.

Example: addis 3,3,4

In this example GPR3 and the value 4 are added, then GPR3 is shifted 16 bits to the left and the result is put into GPR3. This will then contain 0x00040000 in hexadecimal. If you then execute an addi 3,3,4 command GPR3 will contain 0x00040004 in hexadecimal.

To move a pointer to an address of a variable or function into a register there are the @ha/@h and @l modifiers available. If you append these to the variable name you get the lower (@l) 16 bit of the absolute 32-bit address of the variable and with @ha you get the higher 16 bit of the absolute 32-bit address.

Example:

addis 3,0,hello@ha
addi 3,0,hello@l
With these two instructions the absolute 32-bit address of the string variable hello is moved into the GPR 3 register.

Instead of addis/addi the mnemonics lis/la are often used.

@All
Is anyone know if old WarpOS support "unalignment memory access" ?

What i mean, were these exceptions handled and emulated by WarpOS and by our powerpc.libraries be it old Joerg's one, or new one from Hedeon ?

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..

@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?

@Hedeon

Quote:

Because seems that this code on which i always crashes does not take care about alignment:



"lhz" reads 16 bits from the first argument passed pointer, which is incremented by 1 with "addi r3,r3,1" at the end of the loop.

While my crash is DSI, and point out that issues is with second argument, i think this unaligment thing can cause this and explain why i crash not from the first call to this function, but from second.

Have maybe any idea how to "align" this part for fast check ?

@kas1e
Quote:Of course my powerpc.library includes an alignment exception hander, but I don't remember if it only emulates unaligned float/double accesses, which is required for nearly all WarpOS software using the FPU, or unaligned integer accesses as well.

@kas1e

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

@kas1e



you can write this as:


R3 is source & destionation pointer,
R4 is source pointer.
R10 is the result of shift and mask, also used as offset.
R9 is a base address to some data, because R10 is result of some calculation.
for "bdnz" to work CTR has to be set some where before the loop.
Make sure R3,R4 and r9 points to something valid.

this two can be removed, not doing anything useful.

In the first post there's the whole code.
Maybe instead of debug ASM it can be rewritten in C, it's quite short.

@LiveForIt
Quote:Check for example rlwimi

@Hedeon
Quote:No. While 16 bit accesses, as in those sources, should work on any PowerPC CPU supported by AmigaOS 4.x, be it e300, e400 or e500 API ones, 32 and 64 bit accesses to odd addresses may not be supported by all of those PowerPC CPUs.
POWER CPUs, like the P6T in the X1000, may have even more strict alignment requirements for integers.

@joerg

Quote:

I have not noticed an issue with that, but it will slow down the program if you have misalignments.

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.

@Hedeon
Quote:IIRC the FPU in the 440ep used in the Sam440ep isn't in the CPU core but external to it and crossing a cache line with a FPU access causes an alignment exception, which isn't the case for example on 60x, 750 and 74xy CPUs.
You don't get an alignment exception in your programs because the alignment exception handler in the 440ep HAL of the kernel takes care of it, but of course that's very slow.
It's probably the same for the 460 CPUs.
Quote:If it would be an alignment problem he should get an alignment exception instead of a DSI one.

@LiveForIt
Quote:If it's not just a little bit slower it may be because it's emulated by an integer alignment exception handler in the kernel, just like the FPU one for the 440ep.

@joerg

But this code snippet does not use any FPU instructions, it only uses integer instructions.

rlwimi r10,r11,0,16,31
rlwimi r10,r11,0,24,31

can be both replaced with
andi r10,r11,0xFFFF
andi r10,r11,0xFF

compiler has generated a complex instruction instead of a much simpler one

About DSI crash it could be a previous mem allocation bug, so pointers r3 and r4 can exceed limits.