<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
The frontend/backend interface should have notions of record field accesses and array indexing.<BR>
I'm not sure exactly what they should look like but it shouldn't be difficult to figure out,<BR>
at least some simple approaches that scale well enough, even if not ideally.<BR>
<BR>
<BR>
For example, every field in a record should either have an id 0, 1, 2, etc. allocated within the record.<BR>
OR every field in a record should have an id a la hashes/fingerprints, that could be<BR>
sorted/searched globally, even if that isn't as efficient as it could be.<BR>
<BR>
<BR>
What I'll probably get working before any of this is in m3_load/store, do a linear search within<BR>
the fields of the variable for a field whose offset/size matches.<BR>
But linearch search is almost never a good solution.<BR>
It could be implemented as binary search with the current interface.<BR>
<BR>
<BR>
Due to the danger of layout mismatch, I'm plenty willing for field/array accesses to include<BR>
with them the offset the frontend believes them to be at, and it'd be a checked internal error<BR>
in the backend if the frontend and backend offset/size disagree.<BR>
This would also aid backends that don't have such a high level internal representation (i.e.: NT386).<BR>
<BR>
<BR>
I have something prototyped here and it somewhat works.<BR>
I have a check that all accesses can be have a field deduced for them.<BR>
The first place that fails is for open arrays, for obvious reasons, which I'll fix.<BR>
I'll see how it goes from there.<BR>
<BR>
<BR>
Ultimately I'm still keen on a C-generating frontend, which does not moot this.<BR>
It would allow for more sensible C to be generated.<BR>
<BR>
<BR>
<BR>
- Jay<BR> </body>
</html>