<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>I'm wondering if it might just be much easier if m3front assigns<br>small incrementing integers for Var and Proc rather than getting<br>pointers back from declare_procedure, declare_local, etc., and then passing<br>them back to begin_procedure, load, etc.<br><br><br>See, where I am at is I want to "playback" an m3cg run multiple times,<br>computing different data each time -- later runs depending on earlier runs.<br><br><br>I don't need to a persisent "disk" form.<br>Though I end up close to that, esp. with this proposed change, which eliminates some pointers.<br><br><br>I already do this in parse.c.<br>Parse.c being written in C++ and having the preprocessor, it was much easier to do.<br> See how I #include m3-def.h multiple times, with different macros. <br> Ugly perhaps but highly convenient and productive and easy to use..<br>I'm so tempted to write "m3toc" this way, but I'm trying to use the product. It is painful..<br><br><br>Anyway, so I'm using Modula-3, and I have this really tedious code to convert<br>the m3cg calls into an in-memory format. That I'll then loop over multiple times.<br>Due to the tedium, I build up the in-memory format in one shared module,<br>that I'm calling M3CG_MultiPass.<br>It is closely analogous to M3CG_Ops.i3:<br><br><br>TYPE declare_exception_t = REF RECORD name: Name; arg_typeid: TypeUID; raise_proc: BOOLEAN; base: Var; offset: INTEGER END;<br><br><br>PROCEDURE set_runtime_proc(self: T; name: Name; proc: Proc) =<br>BEGIN<br>self.Add(NEW(set_runtime_proc_t, name := name, proc := proc));<br>END set_runtime_proc;<br><br><br>etc.<br><br><br>so, now, for this in-memory format to be used by arbitrary other backends..I think these "Var" and "Proc"<br>will become a sticking point. I think we need a backend-independent way to refer to them.<br>I think INTEGER is the way. Like how M3CG_BinWr deals with them.<br>The downside/cost is that in M3x86.m3, rather than directly using the pointer (after narrow),<br>it will instead index into its own private array.<br><br><br>For efficiency, maybe some hint would come to the backend early as to how large to make the arrays?<br>Or maybe that defeats some of the design -- the single pass implementations.<br>(m3front is many-pass anyway, right? All this single-pass stuff is kind of only theoretical, right?<br>The compiler working-set is not small and fixed size, but rather scales with module size, right?)<br>Anyway, ok, either way. Backends can just at-least-double their internal arrays as they go.<br><br><br>One might suggest some sort of "multiple playback" based on M3CG_BinWr/BinRd.<br>I'm open to that. But it has some extra unnneeded overhead vs. a typical in-memory representation.<br>I'm also open to changing BinWr/BinRd to use a larger representation that requires "no" decoding.<br>(I've sketched this out myself, but decided it is not a priority. BinWr/BinRd really only<br>exist for licensing reasons and would likely go away if m3cc went away. I think. They are kind<br>of otherwise useful, at least during development.)<br><br><br>Thoughts?<br><br><br><br> - Jay<br> </div></body>
</html>