New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added Sub_Ovh implementation. #64

Merged
merged 2 commits into from Nov 28, 2018

Conversation

Projects
None yet
4 participants
@Geramy
Contributor

Geramy commented Jul 25, 2018

I added the Sub_Ovh Implementation next is the Sub_Ovh_Un Implementation this is for ticket: #9

Added Sub_Ovh implementation.
I added the Sub_Ovh Implementation next is the Sub_Ovh_Un Implementation this is for ticket: #9
@mterwoord

This comment has been minimized.

Contributor

mterwoord commented Jul 25, 2018

Can you please include a test which proves this change works as expected?

Fixed Implementations
Had to use a hack to fix stack problem with exceptions

Added Sub_Ovf_Un IL Opcode
@jp2masa

jp2masa approved these changes Oct 9, 2018

}
// Let's check if we add overflow and if so throw OverflowException
XS.Jump(ConditionalTestEnum.NoOverflow, xSuccessLabel);
if (xSize > 4) // Hack to stop stack corruption

This comment has been minimized.

@jp2masa

jp2masa Oct 9, 2018

Member

This is something we will have to consider on exception handling. When throwing in the middle of an opcode, this will probably work for most of the simple cases, but not sure about more complex ones. I'm not sure about what the CLI spec defines for the stack, still have to read that, but if the following is valid IL:

try
{
    ldloc.0
    ldloc.1
    ldloc.2
    add.ovf
    add.ovf
}
catch
{
    // do something
}

And we throw at the first add.ovf, the stack is not in a good state to jump to the catch block (still has the other local on the stack, which was expected to be consumed by the second add.ovf). Roslyn seems to emit good IL for this (not sure if by spec, still have to check), so this should work for now.

Also, I think we should file an issue about this or add this info to #16.

This comment has been minimized.

@jp2masa

jp2masa Oct 9, 2018

Member

According to ECMA-335, the throw opcode description is this:

The throw instruction throws the exception object (type O) on the stack and empties the stack.

So I think we should always empty the stack when throwing an exception, we should add some common infrastructure to throw exceptions, probably part of #16, I'll add a note there.

@mterwoord mterwoord merged commit ecab282 into CosmosOS:master Nov 28, 2018

1 check passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details

@jp2masa jp2masa referenced this pull request Nov 28, 2018

Closed

Implement sub.ovf.un #10

0 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment