[Vm-dev] Moving simSelf into simStack and eliminating optStatus
Ronie Salgado
roniesalg at gmail.com
Tue Jan 23 05:37:51 UTC 2018
Hi Eliot,
Second, Ronie, in looking at ssFlushTo:nativeFlushTo: it seems to me that
> it is only ever called with nativeIndex being supplied
> from simNativeStackPtr. If you agree with me that that is the case would
> you object to me deleting ssFlushTo:nativeFlushTo: and
> implementing ssFlushTo: to include LowcodeVM ifTrue: [self ssNativeFlushTo: simNativeStackPtr]?
> This is a little cleaner, We can always make it more complicated later on
> if required, but right now I'd like to keep things as simple as possible.
>
Sounds fine by me.
BTW, we should have some talk during one of these days.
Best regards,
Ronie
2018-01-22 22:47 GMT-03:00 Eliot Miranda <eliot.miranda at gmail.com>:
> Hi Ronie, Hi Clément, Hi All,
>
> one poor design decision I made when writing
> StackToRegisterMappingCogit was in keeping simSelf, the simulation stack
> entry for the receiver, separate from simStack, the simulation stack
> entries for the stack proper. I'm now at a point where I want to get
> RegisterAllocatingCogit working properly so that soon Clément and I can
> merge it into the SistaCogit and get much improved register allocation for
> Sista/Scorch. So I'm starting by duplicating StackToRegisterMappingCogit
> and making the changes in the city so I can verify that the existing one
> and the new one without simSelf or optStatus generate exactly the same code.
>
> First of all, is that ok with both of you?
>
> Second, Ronie, in looking at ssFlushTo:nativeFlushTo: it seems to me that
> it is only ever called with nativeIndex being supplied
> from simNativeStackPtr. If you agree with me that that is the case would
> you object to me deleting ssFlushTo:nativeFlushTo: and
> implementing ssFlushTo: to include LowcodeVM ifTrue: [self ssNativeFlushTo: simNativeStackPtr]?
> This is a little cleaner, We can always make it more complicated later on
> if required, but right now I'd like to keep things as simple as possible.
>
> _,,,^..^,,,_
> best, Eliot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180123/4ee2d4b8/attachment.html>
More information about the Vm-dev
mailing list