[Vm-dev] Direct pointer vs pointerForOop()

[Eliot Miranda]

Hi Subbu,

> On Apr 9, 2018, at 1:50 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> 
> On Sunday 08 April 2018 04:51 PM, Eliot Miranda wrote:
>>> This is a really good fix, but it won't stop compilers warning
>>> about mixing ints/pointers:-(. sqMemoryAccess.h has many comments
>>> like: ----- sqInt is a signed integer with size adequate for
>>> holding an Object Oriented Pointer (or immediate value) .... ---
>>> Such intents can be captured in directly in a single union.
>>> Arch-independent code could use oop or oop.asOop while different
>>> implementations could choose different representations (oop.asAddr,
>>> oop.asOffset, oop.asInt, etc) without having to use casts. I have
>>> tried using both casts and unions in my other projects, and the
>>> ones with unions proved to be compact, readable and compiled
>>> without type warnings.
>> No.  Using a union requires a huge rewrite of all of the platform
>> code and VMMaker.
>> A feasible change is to replace sqInt globally with e.g. sqOop where
>> sqOop is an anonymous pointer:
>> typedef sqOop struct _opaque_object *;
> 
> This won't help eliminate compiler warnings about mixing int/pointers. We should be taking such warnings seriously as they could hide bugs.

Agreed.  But they are fixed by rewriting the appropriate code in VMMaker.oscog of the plugin packages or the platform C code.

> The problem in OP happens when sizeof(int) < sizeof(void *). size_t does not face the problem. Why not
> 
> typedef size_t sqOop;
> 
> Now the compiler will catch sqInt/sqOop mixups. We can then use macros (shortened to fit mail line) to convey intent :
> 
> #define i2oop(n)    ((sqMemoryBase - (char *)0) + (n))
> #define addrAt(oop)    ((char *)0 + (oop))
> #define oop2i(oop)    (addrAt(oop) - sqMemoryBase)
> 
> will work on 32image/32vm, {32,64}image/64vm

Ugh.  I don't want to support sqMemoryBase at all.  It's yet more effort for little return.

> 
> Regards .. Subbu