[Vm-dev] Sometimes it's too easy, part II

[Eliot Miranda]

Hi Bert,

> On Jan 26, 2017, at 2:42 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 
> Awesome! However ...
> 
>> On Wed, Jan 25, 2017 at 6:22 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> The default type for oops in the VM is sqInt (*), which is signed.
> 
> ... since this keeps biting us time and time again, how hard would it be to change? Defaulting to unsigned seems much more reasonable, no? Unless we're dealing with SmallIntegers, which have to be special-cased anyways, we never want unsigned behavior, right?

well, I've wanted to change this for some time but potentially it's a lot of work, as it affects the plugin and platform support code as much as the VM source.  But let's at least discuss it.

First, what exactly do we do?  Right now we have sqInt & usqInt as oop-sized signed and unsigned types.  My list of pros and cons below is off the top of my head, preliminary.  Most of the below share the issue that we have to identify places where signed SmallInteger arithmetic is done and re-type them appropriately.  Do we

- a) change the code generator to use usqInt as the default type in place of sqInt?
   pros presumably minimal changes except to code generator and removing pragmas that specify usqInt?
   cons rewriting platform support code to use usqInt for at least parameters

- b) add a new default type, e.g. oop_t, which is the same as usqInt?
  pros, see above
  cons figuring out which usqInt types apply to oops and which to unsigned values

- c) change sqInt to be unsigned and add e.g. ssqInt as a signed type
   pros don't have to change platform source
 
- d) add a new default type, e.g. oop_t, which is the same as char *?
   pros oops are pointers 
    cons C allows arithmetic on char *, so this won't fix inappropriate arithmetic on oops
         It's undefined in C whether pointers to different structures can be compared (but I do not know if an implement ration that refuses to compare pointers as simply addresses)

- e) use void * instead of char * (too horrible bow to contemplate cuz one can't compare void *)

- f..z) ?

Bert, is there a similar analysis for SqueakJS or are the C types irrelevant and ignored?

Anyway, looks to me like a) or c) are the main contenders.  What d'all think?

> 
> - Bert -
> (*) fixed the typo
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170126/257dd803/attachment.html>