[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Scratch registers
On 12/08/2014 16:08, Miro Kropáček wrote:
I've bumped into an interesting issue (thanks ggn!) -- it's not a secret
that TOS uses a0-a2/d0-a2 as so called scratch registers.
"TOS" is too general.
Rules may be different for GEMDOS, XBIOS, AES, etc.
But indeed, when calling GEMDOS, we must assume that a0-a2/d0-a2 may be
trashed.
However, this seems to be not true for TOS earlier than 2.x,
I always test GCC stuff with TOS 1.62 and the rules seems to be the same
as usual.
i.e. TOS utilizes only d0/a0 as the scratch registers
When?
When calling GEMDOS? Yes, it is often the case. But it does not mean
that d1/d2/a1/a2 will always be preserved. They must be backuped before
any trap #1, just in case.
and the other registers must be preserved.
This sentence has no sense from the user point of view.
Do you mean "preserved" when you write your own trap #1 hook?
Actually, I believe that a lot of old software assume that d1/d2/a1/a2
will not be modified by a trap #1 call. So if some driver hooks the trap
#1 and clobbers d1/d2/a1/a2, even if it is perfectly valid it may crash
the old software making wrong assumptions.
In practice, it doesn't pose much problems as there are very few people
running gcc+mintlib apps on TOS 1.x machines but it is a problem in general.
As previously said, I always test gcc+mintlib apps on such TOS.
For me the use case is a GEMDOS driver/handler -- I call a C function
from my asm code, d1/d2/a1/a2 get trashed,
No, C functions compiled with GCC only trash d0/d1/a0/a1.
I pass execution back to TOS and bam, crash because the original TOS
handler expected the regs wouldn't change.
You should clearly identify the caller of your code, and identify its
expectations. Maybe the caller is some kind of "software making wrong
assumptions" I discussed above.
Of course, I could (and will) store the regs before calling the C
function
If you want to support poorly written user software (and I think it's a
good idea, since old software will not be fixed), you just have to
backup d1/a1 in your trap #1 handler, and that will be enough. GCC will
backup d2/a2 automatically, and we don't have to care about d0/a0.
but in general, it's a bug, not so well known, as the rule for
scratch registers had changed after TOS 2.x release.
If this is true, this should be documented.
But I believe that the rule varies across TOS versions *and* different
function numbers.
--
Vincent Rivière