[Rpcemu] Code review

Timmermans, Andre andre.timmermans at atos.net
Tue Feb 21 23:25:32 PST 2012


For example:

        if (!(opcode&0xFF0)) /*No shift*/
        {
                addbyte(0x8A); addbyte(0x0D); addlong(pcpsr+3); /*MOVB *pcpsr,%cl*/
                generateload(opcode&0xF);
                addbyte(0x80); addbyte(0xE1); addbyte(~0xC0); /*AND $ZFLAG+NFLAG,%cl*/
                return 1;
        }
No shift but clears C flag.

Second example:

                case 0x00: /*LSL*/
                addbyte(0x8A); addbyte(0x0D); addlong(pcpsr+3); /*MOVB *pcpsr,%cl*/
                generateload(opcode&0xF);
                if (temp)
                {
                        addbyte(0x80); addbyte(0xE1); addbyte(~0xE0); /*AND $ZFLAG+NFLAG+CFLAG,%cl*/
                        addbyte(0xC1); addbyte(0xE0); addbyte(temp); /*SHL $temp,%eax*/
                        addbyte(0x73); addbyte(3); /*JNC nocarry*/
                        addbyte(0x80); addbyte(0xC9); addbyte(0x20); /*OR $CFLAG,%cl*/
                }
                else
                {
                        addbyte(0x80); addbyte(0xE1); addbyte(~0xC0); /*AND $ZFLAG+NFLAG,%cl*/
                }
                return 1;
Here if temp is 0, there is no shift but it clears C flag.
If temp is non-0, current C flags is kept (it should be cleared) before the SHL and set to 1 if required after the SHL (correct).

André

________________________________
From: rpcemu-bounces at riscos.info [mailto:rpcemu-bounces at riscos.info] On Behalf Of Tom Walker
Sent: mardi 21 février 2012 21:04
To: rpcemu at riscos.info
Subject: Re: [Rpcemu] Code review

> I have also looked at the file codegen_x86.c.
>
>The function generateshiftflags() seems to be mishandling the C flag
>(at least if the comments match te actual opcodes used).

Can you point to specific examples of this? I've just had a look and every area where this seems to be a problem is preceded with 'return 0;' - ie fall back to interpreter code.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riscos.info/pipermail/rpcemu/attachments/20120222/85c28817/attachment.html>


More information about the Rpcemu mailing list