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

[Jay K]

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

> BYTESIZE(INTEGER)
I know this is trickier but I consider it almost the same problem.
Imagine I have this C code:
typedef struct T1 { size_t a,b; } T1;T1* pt1;
pt1->b
(*size_t*)(((char*)pt1) + sizeof(size_t))

while the second is not idiomatic, and may skirt alignment/padding rules (imagine if a was a char and b a size_t), it is just about as portable.

And you can write Modula-3 that way, with LOOPHOLE, ADR, BITESIZE, etc.

I think "expressions" or "constant expressions" need to be maintained in "string" or "structural" form and passed to the backend..."string" would be, like, the original Modula-3."structural" would be parse them and make an "expression tree" with nodes like plus, minus, multiplication, division.

I think, perhaps, the expression tree would be optional. Backends that ignore them could say so and save that cost.
I believe most/all Modula-3 constant expressions render trivially in C.
Really, like,RTIO.PutInt(BYTESIZE(INTEGER));
ideally translates to C involving the string/type "INTEGER", and not INT32 or INT64.
I have to go.
 - Jay

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


On Aug 10, 2015, at 2:23 PM, Jay K <jay.krell at cornell.edu> wrote:I want load/store of field names, or of constant array indices, to include a string or M3.ID indicating the field name.
A cleaner solution is to use types and request the nth field of the type, etc.  That way we don’t need symbolic names for the fields.
This way, the C backend can avoid hardcoding the offsets. A step toward target-independent generated C.
Ok?

Similarly, I want expressions involving BYTESIZE(INTEGER) or BITSIZE(INTEGER) or BYTESIZE(pointer) or BYTESIZE(RECORD or ARRAY involving INTEGER or pointer) etc. to be in a state that the C backend can render them in a target-independent way. Thoughts?
That is a bit trickier if not impossible.  Modula-3 inherently exposes these as compile-time integer constants.

Basically, I want to generate one version of C that works on all targets.Currently we are far from that, and it isn't easy.The jmpbuf change was a small step in that direction.

  - Jay


_______________________________________________M3devel mailing listM3devel at elegosoft.comhttps://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150810/0069030f/attachment-0002.html>