From: | Frank Wille |
Date: | 17 Jul 2000 at 20:49:40 |
Subject: | Re: Run68k yet a trouble |
Almos Rajnai wrote:
> On 16 Jul 00, at 19:21, Frank Wille wrote:
>
> > The 68k-part is ok, although I would place the variables you want to
> > access from the PPC-side, like _PowerPCBase, into the TOC section:
>
> Why should I place into the .tocd section?
As I said some lines below, you can access _PowerPCBase with
move.l _PowerPCBase(a4),d0
for M68k, and with
lwz r3,_PowerPCBase(r2)
for PPC. Currently you will need
lwz r11,@__PowerPCBase(r2)
lwz r3,0(r11)
on the PPC-side, because _PowerPCBase is not part of the TOC.
> BTW to avoid cache problems,
> "dcb.b 32,0" would be better at the end of a section,
At the end of the sections you could just link with vlibwos:x.o.
> the beginning should be cache-aligned. (At least this seems
> obvious to me, but please correct my words.)
A section is not PPC cache aligned, which means 32-bytes aligned.
A section is only guaranteed to be 8-bytes aligned. When this
section is loaded somewhere into memory, besides M68k-only memory,
cache problems are possible.
> > By doing so you can access _PowerPCBase via A4 on the 68k-side and
> > directly via R2 (rtoc) on the PPC-side.
>
> All data sections can be accessed via rtoc, because they are merged
> together. (It is working, I tested it.)
Sigh. Yes, vlink will merge everything, if you force it to do so.
But with this style your programs may never get larger than 64k. ;)
> > So when Run68k() saves CR, LR or whatever in this stack frame, it will
> > destroy your PPCArgs structure.
>
> This caused the trouble. Finally I found out, thank to fd2libWOS...
> :) Should I initialize somehow this stack frame?
I would insert these lines at the beginning of the function:
mflr r0
stw r0,8(r1) # save LR in caller's stack frame
stwu r1,-160(r1) # new SF: 160 bytes should be enough
Note that the first 24 Bytes are the minimum reserved for the
PowerOpen stack frame, so your PPCArgs structure may not start
before 24(r1).
addi r11,r1,24
stw _d0,PP_REGS(r11)
stw _d1,PP_REGS+1*4(r11)
stw _d2,PP_REGS+2*4(r11)
[...]
Remove stack frame and restore LR at the end of your function:
addi r1,r1,160
lwz r0,8(r1)
mtlr r0
blr
> Code generated by fd2libWOS does no init at all. (?)
What? The code which my fd2libWOS generates, makes a perfect
PowerOpen stack frame.
> Local labels can be used somehow in pasm?
Sorry, but this feature is still missing. Maybe in a future
release. I have plans for pasm V2, a portable assembler for
multiple CPUs and object file formats.
> And sometimes pasm does not stop when it found an error in a
> macro.
Please send me an example source and I will try to fix it.