[M3devel] "get member reference" /load/store(field name)?

[Jay K]

> BYTESIZE(INTEGER)
I have other ideas here.

 1) Give up. Be like the 3.6 release and have target-specific boot archives, and target specific intermediate C, like current.

 2) kinda of compile everything twice. The generated C would be: 
 #ifdef _LP64_ // or such  
 ... 
 #else 
 ... almost but not quite the same  .. 
 #endif 
To cut down cost somewhat, rereading dead code, it could be: foo32.c  foo64.c  foo.c  #ifdef _LP64_  #include "foo64.c"  #else #include "foo32.c"  #endif 

  3) Sort of compile as always/only 64bit, when using C backend.  
  Specifically, in m3middle/Target.m3, when using C backend, setup 64bit types. 

  And in M3C output something like: 
  #ifdef _LP64_ /* or such -- not quite*/  
  #define PAD64(x) /* nothing */  
  #else  
  #define PAD64(x) int x##pad;  
  #endif 
  RECORD T1 =   
   a: REF INTEGER;  
  END;  
  =>  
   struct T1   
   {   
    INTEGER* a;   
    PAD64(a);  /* after any pointer field in a record */  
   }; 

  This is an efficiency loss on 32bit platforms but maybe ok. 
  It would gain a certain compatibility, i.e. in persistance formats.   Local variables not in a record..would possibly be put into such a record, depending on if we could guarantee the entire pointer doesn't get overwritten..consider unusual valid Modula-3 such as:   Cstring.memset(ADR(ptr), 0, BYTESIZE(ptr)); 

 so we would have to pad out locals also. Possibly subject to #ifdef _LP64_. 

 Big problem here would be interfacing with actual C code.
 For example Win32 and X Windows. If not for that, I was thinking this is a very viable approach. Given that, I'm not sure.
 Maybe as I was saying really kind of preserve all constant expressions symbolically and let the C backend rerender them.including stuff like: a: ARRAY [0.. BYTESIZE(INTEGER)] OF CHAR. or a: ARRAY [0.. BYTESIZE(INTEGER) * 2] OF CHAR. or a: ARRAY [0.. (BYTESIZE(INTEGER) = 32) * 4 + (BYTESIZE(INTEGER) = 64) * 8] OF CHAR. 
would have to be certain basically what is constant in Modula-3 is constant in C.
 - Jay




Subject: Re: [M3devel] "get member reference" /load/store(field name)?
From: hosking at purdue.edu
Date: Mon, 10 Aug 2015 17:02:37 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu


On Aug 10, 2015, at 4:55 PM, Jay K <jay.krell at cornell.edu> wrote:Interesting. I hadn't thought of that.
We do "need" symbolic names. Well..they could be omitted, but:
 - Having symbolic names is great for debugging, vs. making up names.
The names are in the type.
 - This assumes between C and Modula-3 the rules for the naming are close enough. I already handle things like if you have a record field named "int", I change it. For every reserved word as far as I knew (something I needs to be checked against K&R, ANSI, and C++latest).

This idea of "nth" then unifies constant array indices with record fields?

Yes.
I would have likely had two parameters, a string/id and an integer.Or two different functions.
Oh..I guess this isn't to avoid the strings, but pass them when defining the type,and not repeatedly for access?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150810/389dd842/attachment-0002.html>