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

[Ben Coman]

On Fri, Jan 27, 2017 at 12:52 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> 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?

What is the overlap in the cons between a) and b) ?
Is one a super-set of the other or are the changes orthogonal?

For stability during the progressive work on a)
would it help to anyway replace sqInt by oop_t,
and have an experimental branch where "typdef usqInt oop_t"
while the main Cog branch remains "typedef sqInt oop_t" ?

cheers -ben