<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Clarification: I now see that 3.6 did have these tables. They had different names. It appears they were generated for every ...I don't know, every source file or every .dll/.exe. That would work. That is similar to what we have now with my fix, though my fix statically links more than this -- everything in hand.obj.<BR>
<BR>
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.m3(2033):PROCEDURE init_intvar (t: T; size: ByteSize; f_lit: FLiteral; abscall: AbsCall;<BR><BR>
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.i3(96):TYPE IntnlVar = { Lowset_table, Highset_table };<BR>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Codex86.m3(2077): <FONT face="">IntnlVar.Lowset_table</FONT> =><BR>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1953): o := ORD(<FONT face="">IntnlVar.Lowset_table</FONT>),<BR><BR>
D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(34): lowset_table : MVar;<BR>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1298): t.cg.tableOp(Op.oAND, stop2, stop0, 4, t.lowset_table);<BR>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1430): t.cg.tableOp(Op.oMOV, t.cg.reg[maskreg], stop0, 4, t.lowset_table);<BR>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1443): t.cg.tableOp(Op.oMOV, t.cg.reg[maskreg], stop0, 4, t.lowset_table);<BR>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1495): intable := t.lowset_table;<BR>D:\cm3-4.1\CONTRIB\SRC-M3\m3\m3back\src\Stackx86.m3(1952): t.lowset_table := MVar { var := t.cg.internalvar,<BR><BR>
That at least clarifies there wasn't likely an older less efficient table-less codegen, just that the tables were gotten differently.<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: m3devel@elegosoft.com<BR>Subject: _lowbits / _highbits (Pixmap bug-- 4.1 vs. buggy 5.x)<BR>Date: Sat, 10 May 2008 15:40:40 +0000<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
There is SOME evidence that this lowbits/highbits<BR>problem is a regression introduced in Critical Mass 5.1.<BR>And there are inconsistent data.<BR>(I believe 5.1 is the name given to the Critical Mass tree at the time it was open-sourced, vs. 4.1 which was commercially released, and some source withheld.)<BR><BR> <BR>The source history is a little incomplete.<BR>Critical Mass 4.1 did not ship with complete source.<BR>In particular, the compiler source is missing.<BR>Libraries are there.<BR><BR> <BR>Aside: I wonder if the 4.1 release can be made more widely<BR>available, for purposes such as this. For one thing, I can contribute<BR>how to trivially patch the NT386 binary to not care about the registration key.<BR>I did buy it, but finding the key is..difficult.<BR><BR> <BR>The Elegosoft repository claims to have an import of 4.1<BR> followed by an update to 5.1, but it is suspicious.<BR> <BR><BR>3.6 Stackx86.m3 -- no reference to _lowbits / _highbits<BR>3.6 hand.c -- no implementation of ditto<BR>3.6 didn't offer dynamic linking, so it would have been ok.<BR><BR> <BR>The 4.1 CD includes the 3.6 source in "contrib" and some of the<BR>4.1 source in "source". That confused me at first, to have two of everything.<BR>I merely ASSUME what is what. I didn't look in detail.<BR><BR> <BR>4.1 CD hand.c -- no implementation of _lowbits / _highbits<BR>4.1 CD Stackx86.m3 -- source not available, darn it<BR> <BR><BR>4.1 in repository hand.c -- no implementation of ditto<BR>4.1 in repositoy Stackx86.m3 -- references _lowbits / _highbits<BR><BR> <BR>5.1 in repository hand.c -- implementation of ditto<BR>5.1 in repositoy Stackx86.m3 -- no change<BR> <BR><BR>The supposed 4.1 to 5.1 lack of diff (not that I understand CVS revision numbers or anything...) <BR><A href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1" target=_blank>http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3.diff?r1=1.1;r2=1.1.1.1</A><BR> <BR><BR>introduction of _lowbits / _highbits in a more belieable 4.1 to 5.1 diff:<BR> <A href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2" target=_blank>http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c.diff?r1=1.1.1.1;r2=1.1.1.2</A><BR><BR> <BR>This is all a bit tedious so someone please double check me.<BR> <BR><BR>The 4.1 source in the repository is not self consistent.<BR>I contend it is wrong.<BR>I contend that the 4.1 Stackx86.m3 is more like the 3.6 -- no use of highbits / lowbits.<BR>Since the symbols are not exported from the 4.1 CD m3core.dll nor are in the 4.1 CD hand.c source.<BR> <BR><BR>5.1 in the repository is self consistent, and I contend has the bug.<BR> <BR><BR>The 4.1 m3core.dll does export HiBits / LoBits -- different spelling, different casing,<BR> and none of the .dlls in the system import them.<BR><BR> Several versions have LoBits / HiBits be file-level static, further<BR> implying they aren't used outside of hand.c.<BR><BR> It is difficult for me to browse the old version of the tree however.<BR> I guess I should try something like checkout -revision 1 and then search that locally?<BR><BR> Inspection says that HiBits / LoBits went static in 2003 here:<BR> <BR> <A href="http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c" target=_blank>http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/Csupport/Common/hand.c</A><BR> <BR> and then later, I made them non-static FOR 32 BIT TARGETS, as part of merging them with<BR> _lowbits / _highbits. This is a bit tangential, but the point is to exonerate<BR> LoBits / HiBits of any involvement. _lowbits / _highbits are the relevant party.<BR> They are nearly identical. See hand.c for how they relate. There is an extra<BR> entry in one pair or the other, either at the start or the end, and one is uint and the<BR> other ulong, when sizeof(uint) == sizeof(ulong), they share storage, my doing.<BR> The NT386 compiler references _lowbits / _highbits. LoBits / HiBits are only used internally to hand.c.<BR> The gcc backend does not reference _lowbits / _highbits.<BR><BR>So obviously another fix is to go back to the 3.6 code and remove the symbols entirely.<BR>And make sure m3tests passes with that.<BR>I didn't look at the code yet.<BR>In general the code quality is not super high so it probably matters little.<BR><BR>Also obviously it would be prudent to review the code here to make sure it is correct,<BR>or to look at the relevant unit test and see if it seems comprhensive.<BR> <BR> <BR>Thoughts?<BR> <BR> <BR>Presume Critical Mass introduced the regression in 5.1, and give up attaining accurate 4.1 source??<BR>I should findstr (grep) against the 4.1 cm3, but the lack of the symbols in its m3core is pretty conclusive.<BR> <BR><BR> - Jay<BR></BLOCKQUOTE></body>
</html>