[Vm-dev] Direct pointer vs pointerForOop()

K K Subbu kksubbu.ml at gmail.com
Mon Apr 9 08:50:11 UTC 2018


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. 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

Regards .. Subbu


More information about the Vm-dev mailing list