[M3devel] cost of opaque types

[Jay K]

If my opaque type exposes no public data, only functions, then I think I'll win significantly by just using "fully transparent prefix object types". 
I have to check if method calls incur a similar extra overhead. 
You know, if you have: 
TYPE T <: OBJECT METHODS
  F1();
END;NEW(T); 
vs. interfaceTYPE T = OBJECT METHODS
  F1();
END; module TYPE TImpl = T OBJECT more stuff END;PROCEDURE CreateT():T = BEGIN RETURN NEW(TImpl); END CreateT; 
the level of opacity is the same, but the second form likely has much lower overhead. 
The difference being that you can't directly NEW the type, you
have to use a special creator function. 
Debugging might might might be better in the first case, esp. with stock debuggers, if the backend has or finds enough information (imagine -- backend doesn't really have to be unit-at-a-time..it can sit around building everything in memory..waiting for all the type revelations..and generate everything into one C or .asm or whatever file...) That is, the second case is common in C++ a la COM, and debuggers
often only show a vtable and function pointers -- the base type.
They ought to figure out from the vtable the leaf type and show
everything..maybe Visual Studio does..I use windbg more...  
 - Jay



 Subject: Re: [M3devel] cost of opaque types
From: dragisha at m3w.org
Date: Wed, 3 Apr 2013 15:03:31 +0200
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

There are languages, C# and Java coming to mind. where people accept a lot more from language/compiler for various reasons. 
:)

--Dragiša Durićdragisha at m3w.org



On Apr 3, 2013, at 10:46 AM, Jay K wrote:cost of opaque types


fyi:

    PutI(cstr("Public.F1.a.c"), a.c);


PutI == put_adr
L_22_L_23 the string
L_26_L_27 == a
8 is the "public offset" of c
M_Public_L_19 globals for Public.m3


everything else is the computation of the "public base" of a from the base of a


actual C backend output cm3/m3-sys/m3tests/src/p2/p253/AMD64_DARWIN/Public.m3.c


put_adr(((ADDRESS)(L_22_L_23)),((ADDRESS)(((8)+(ADDRESS)(((ADDRESS)((((ADDRESS)(L_26_L_27))+(1* /* cast_removed2: INT64 */ *((INT64*)(M3_INT64(112)+((ADDRESS)(*((ADDRESS * )(M3_INT64(176)+((ADDRESS)((ADDRESS)&M_Public_L_19)))))))))))))))));


simplify slightly (how I wish it got printed...):

put_adr(L_22_L_23,8 + L_26_L_27 + *(INT64*)(112 + *(ADDRESS*)(176 + (ADDRESS)&M_Public_L_19)));



I still have to track down the whole "recompile again now that offsets are known" path.



 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130403/be9866da/attachment-0002.html>