[M3devel] backend and field/array references
Jay K
jay.krell at cornell.edu
Mon Oct 25 02:21:43 CEST 2010
The frontend/backend interface should have notions of record field accesses and array indexing.
I'm not sure exactly what they should look like but it shouldn't be difficult to figure out,
at least some simple approaches that scale well enough, even if not ideally.
For example, every field in a record should either have an id 0, 1, 2, etc. allocated within the record.
OR every field in a record should have an id a la hashes/fingerprints, that could be
sorted/searched globally, even if that isn't as efficient as it could be.
What I'll probably get working before any of this is in m3_load/store, do a linear search within
the fields of the variable for a field whose offset/size matches.
But linearch search is almost never a good solution.
It could be implemented as binary search with the current interface.
Due to the danger of layout mismatch, I'm plenty willing for field/array accesses to include
with them the offset the frontend believes them to be at, and it'd be a checked internal error
in the backend if the frontend and backend offset/size disagree.
This would also aid backends that don't have such a high level internal representation (i.e.: NT386).
I have something prototyped here and it somewhat works.
I have a check that all accesses can be have a field deduced for them.
The first place that fails is for open arrays, for obvious reasons, which I'll fix.
I'll see how it goes from there.
Ultimately I'm still keen on a C-generating frontend, which does not moot this.
It would allow for more sensible C to be generated.
- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101025/cf3720ff/attachment-0001.html>
More information about the M3devel
mailing list