[Freemint-list] What's wrong with this code?

Miro Kropáček miro.kropacek at gmail.com
Fri Aug 18 05:02:59 MSD 2017


>
> Those are because of the %0+4 etc in the asm, that does not work. The
> solution
> there would be to pass intr_iovar[0] etc instead of doing the arithmetic in
> the asm.
>
Nope, that's not it. Even the first simple %0 has been failing. Also, it's
just a template -- so gcc replaces all the %<number> with a
register/pointer, it doesn't care what's in there. So the key is to have
the constrain set correctly so you wont end up with stuff like (a0)+4 for
instance. I verified my original patch in objdump, gcc 7.1 does its job
properly there.

Thats seems be a oversight in the m68k constraints. There is no constraint
> for
> specifying symbolic references for calls, like in other backends. Whatever
> i
> try, i either get that error or output like "bsr #_pc16550_int" which is
> nonsense of course. Could be solved by loading the address of the function
> into a register first, and passing that as input.
>
Yup, that's my conclusion as well. Seems to be fixed in 7.1, as mentioned.

Your patch wouldn't have worked anyway. The functions are interrupt
> functions,
> and the declaration of the input parameters might generate code that loads
> those values into registers first (generating code to save/restore these),
> but
> the inline asm does a rte already.
>
Good catch!

I have attached a patch that should solve this (relative to your patch since
> it was already applied to master). It also gets rids of that hackish
> pc16550_intx function whose only purpose was to hide the other functions.
>
Your patch wasn't totally correct either -- you use "r" with "(%1)"
(basically proving what I write above -- it's just a string template), this
could easily lead to a construct like (d0), the proper way would be "Q -
Address register indirect addressing mode". Although the hint with "a0"
makes the chance of happening this very low.


>
> PS.: i think most of the asm stuff can be totally eliminated.  There is no
> need to save/restore d2/a2 in the interrupt handler, because that will be
> done
> also in the called function. But i cannot test this, so i left it as it is.
>
I have taken the liberty to go in the proposed direction and got rid of
that crazy and useless asm altogether. See the patch attached. Nothing to
break there, objdump seems to agree (btw do anybody knows why fp0/fp1 are
stored in the interrupt handler with -m68020-60 even though no FPx register
is ever used in given handler?)

PPS: some day someone should go and translate all those german comments,
> also
> in a lot of other source files...
>
True but considering the resources we have available...


-- 
MiKRO / Mystic Bytes
http://mikro.atari.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.atariforge.org/pipermail/freemint-list/attachments/20170818/35ee5acc/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pc16550.patch
Type: text/x-patch
Size: 3584 bytes
Desc: not available
Url : http://mail.atariforge.org/pipermail/freemint-list/attachments/20170818/35ee5acc/attachment-0001.bin 


More information about the Freemint-list mailing list