<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>This is a language question based on the x86 code gen.<BR>It isn't a code gen question at all, just related to m3 constructs the code gen happens to use.<BR>
<BR>The code gen has a stack of operands, I've said many times.<BR>
<BR>This is partly made up.<BR>
<BR> type loc_t = [ imm, reg, mvar ] (* location: variable in memory, register, immediate/constant *) <BR> type reg_t = [ eax, esi, edi, ...] (* register *) <BR>
<BR> type operand_t = record <BR> loc : loc_t; <BR> reg : reg_t; <BR> imm : integer; (* immediate or constant *) <BR> (* some data associated with mvar... *) <BR> end; <BR>
<BR>The type is a bit bigger than this, and that is relevant.<BR>
<BR>interface stack allows access both to entire operands, or their fields, based on an index into the stack.<BR>
<BR>The stack is not fixed size. I think this becomes important.<BR>
<BR> Pardon my mix of M3, C, C++ and made up syntax. <BR>
<BR> interface and module stack; <BR>
<BR> private s: array of operand; <BR>
<BR> procedure getloc(n: integer) : loc_t = <BR> begin <BR> return s[n].loc; <BR> end getloc; <BR>
<BR> procedure getimm(n: integer) : INTEGER = <BR> begin <BR> return s[n].imm; <BR> end getimm; <BR>
<BR> procedure getreg(n: integer) : reg_t = <BR> begin <BR> return s[n].reg; <BR> end getreg; <BR>
<BR> procedure getop(n: integer) : operand_t = (* get entire operand *) <BR> begin <BR> return s[n]; <BR> end getop; <BR>
<BR> A cursory read of the source code, not yet of the object code, from the point of view of a C/C++ programmer<BR>says to me that this last function getop returns a copy of an entire record. Again, the record is a bit larger<BR>than this. I made it still larger, and I started getting warnings about that. <BR>
<BR> What I would really like is for getop to return the operands by pointer. <BR>
<BR> procedure getop(n: integer) : REF operand_t = (* get entire operand *) <BR> begin <BR> return s[n]; <BR> end getop; <BR>
<BR> From my point of view, this is very natural. And far more efficient. <BR> But I couldn't get anything to compile along these lines. <BR>
<BR> Now, as I said, the stack does grow sometimes, so the array could get realloced, and outstanding <BR> pointers invalidated. I guess that is the point? You can't "safely" get a pointer? <BR> I could make it an array of REFs I guess, heap-fragmentation-unfriendly, but given that it grows <BR> rarely, probably ok. <BR>
<BR>I guess maybe gcc does a good job with this stuff? Optimzing away the copies, inlining the array access, etc.?<BR>
<BR> Thoughts? <BR> One just needs to get over worrying about the perf at this level for one's sanity <BR> to survive programming in Modula-3? <BR>
<BR> Safe languages are simply stuck with either a lot of garbage collected separate heap allocations <BR> or a lot of copying? Pointers as I think about them exude "danger" all over the place? <BR> (Yes, I know that "safely" and "danger" are technical terms and I know what they mean, <BR> at least roughly, no dangling pointers to stack, no double frees, no unbounded <BR> array access, no unchecked type conversions, the system remains type safe and <BR> the rules of the language remain unbroken, however I live and breathe C/C++ so it <BR> is hard to adjust my mindset, even if I understand the issues fairly deeply.) <BR>
<BR> The problem one runs into, is that of the pretty darn good C and C++ programmers who, while<BR>not perfect, are pretty darn good. A "safe" language throws you to quite an extreme<BR>of perf compromise to nail the last little bit of guaranteed safety, when you really weren't doing such<BR>a bad job in the first place through brute force of careful coding.. You pay a lot for a little.<BR>Lesser programmers, sure, they need the hand holding... <BR>
<BR>I've been experimenting lately, and C just isn't actually all that bad.<BR>Ok, actually most recently I'm writing more Perl, also not bad.<BR>See, there's another extreme. Traditional and semi-traditional language<BR>and compilation systems like C and Modula-3 and even Java and C# actually<BR>obsess far more about performance than many many problems need.<BR>Perl (Python, Ruby presumably, but Perl is the only one available to me,<BR>that has cleared legal/licensing hurdles) is plenty adequate for tons of tasks.<BR>If my task requires some i/o, then i/o cost might dominate the overall perf cost...<BR>
<BR>I realize I'm all over the place here, arguing for and against optimizing.<BR>
<BR>I don't like Perl's funny characters, or lack of a standard OO approach,<BR>(using hash tables for everything really is bad..) but it's still surprisingly good.<BR>I noticed some job descriptions lately for Perl programmers that specifically<BR>said they were not "scripting" jobs but, like, real industrial strength software engineering.<BR>I think those people get it.<BR>You get to a certain point of general purposeness and performance and hopefully<BR>static checking, and a lot things don't matter as much as people think....<BR>
<BR>Anyway.<BR> - Jay <BR><BR><br /><hr />Share life as it happens with the new Windows Live. <a href='http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007' target='_new'>Share now!</a></body>
</html>