<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I bet this is related to importing (dynamically linking) data -- _lowbits. _highbits and such.<BR>
Dynamically linking data is a bad idea -- the codegen pretty much must vary depending on if you are going to statically link or dynamically link, whereas with functions you can just pretend you always statically link and it works out well enough, just with small lost optimization.<BR>
I don't see getting to this today but should be within a few days.<BR>
<BR>
There is a compromise in that you can make all data that might be dynamically linked pointers to what the data otherwise would have been.<BR>
And then static linking is what loses efficiency -- unnecessary pointer deref.<BR>
Replace all foo with *pfoo, essentially.<BR>
<BR>
The next step would be to change foo to *GetFoo(), even slower, but normal for dynamic linking.<BR>
<BR>
So, anyway, I'll change __lowbits and such to pointers, on NT386.<BR>
I think somehow dynamic linking on other systems copes with this, but I bet it is not pretty if so.<BR>
Dynamic linking on NT writes to generally one page for .so to update one copy of a pointer to all the relevant addresses.<BR>
No writing walk through the code is needed.<BR>
If you are willing to walk through the code and patch it up, then you can dynamically link data without varying the code.<BR>
Or maybe just with -fPIC, all data references are slowed down, in case they are dynamically linked.<BR>
<BR>
I wouldn't be surprised if this has been broken since 4.1..anytime m3core was dynamically linked on NT. Anyone want to try that?<BR>
I should have noticed this earlier, as I did go hunting around for how some of this works.<BR>
<BR>
Anyway, I could be wrong.<BR>
We'll known soon enough now.<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>Date: Sun, 4 May 2008 14:25:26 +0000<BR>Subject: Re: [M3devel] Tinderbox tests on NT386<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>
> That'd be cool if it correlates. <BR> > I'll go try p137 again both ways. <BR><BR>It does!<BR>Standalone p137 and dynamic p137 have very different results.<BR> <BR> - Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>Subject: RE: [M3devel] Tinderbox tests on NT386<BR>Date: Sun, 4 May 2008 14:22:57 +0000<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
I'm also seeing lots of failures in p137<BR> <BR>--- p137 --- bit insert and extract<BR>--- ../src/p1/p137/stderr.pgm 2008-05-04 00:10:01.925067200 -0700<BR>+++ ../src/p1/p137/NT386/stderr.pgm 2008-05-04 03:59:42.382247900 -0700<BR>@@ -1,3 +1,418 @@<BR>+************************ ERROR: 282863103 instead of 819734015<BR>+************************ ERROR: 14427647 instead of 819734015<BR>...<BR>lots<BR><BR>You never saw that Olaf?<BR><BR>I should have printed the test names below, it's too hard to read with just numbers..<BR>Anyway, just looking busy I guess, no matter, we'll get around to them..<BR>(And sorry about the Win32 bitmap stuff, I haven't forgotten...)<BR> <BR>Hm..maybe related? Older version of m3tests statically links to libm3/m3core but current version dynamically links.<BR>That'd be cool if it correlates -- if p137 and the bitmap stuff are the same problem.<BR>I'll go try p137 again both ways.<BR><BR> - Jay<BR>
<BLOCKQUOTE>
<HR id=EC_EC_EC_stopSpelling>
From: jayk123@hotmail.com<BR>To: wagner@elegosoft.com; m3devel@elegosoft.com<BR>Date: Sun, 4 May 2008 14:17:28 +0000<BR>Subject: Re: [M3devel] Tinderbox tests on NT386<BR><BR>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
Here is a QUICK rundown.<BR><BR>p004 I /assume/ this is the same on all platforms<BR> but didn't check<BR><BR>p051 extra print out when building specific to NT386,<BR> fixed, but at great loss of diagnosability IF<BR> there are errors in compiling C code<BR><BR>Specifically, given<BR> cl -nologo -c foo.c bar.c<BR>the compiler prints<BR>foo.c<BR>bar.c<BR><BR>to the same channel as errors (stderr or stdout)<BR>So when running the tests, NT386.common has a hack to throw<BR>out all C compiler output.<BR><BR>p116b floating point issue, probably same on all platforms<BR>p126 ditto<BR>p172 ditto<BR>p186 ditto<BR><BR>p204 compiler bug<BR> I think this also fails on other platforms but obviously<BR> differently; needs investigation<BR><BR>p205 was failing but I put in a fix and then Tony put in a better fix<BR> <BR>p206 I think this fails the same on all platforms, but I <BR> I think it behaves correctly and just update the<BR> std{out,err}.{pgm,build} files; since it is a compilation<BR> failure, it should be an 'e' instead of 'p', not<BR> a big deal I think<BR><BR>p207 probably fall out from longint not being 64 bits<BR> probably should disable just for this platform <BR><BR>r001 This test works in general but is a problem for the<BR> Tinderbox in general. LINUXLIBC6 and NT386 should be<BR> passing, but I think probably it should be turned off.<BR> In particular, the way programs exit when they<BR> fail an assertion and/or have an unhandled exception<BR> varies by platform, in terms of what they actually print.<BR><BR>r002 needs investigation; I think it's an infinite recursion<BR> or just uses a lot of stack, and I THINK I saw it fail<BR> on other platforms <BR><BR>r003 I hadn't looked at this AT ALL but probably the same as r001,<BR> except more interesting?<BR> There is a test that catches an assertion failure, maybe<BR> do that here?<BR> As well, there is the annoying idea of making per-platform <BR> std* files. Hard to maintain.<BR> <BR>r004 ditto -- since there are four of these, and potentially more,<BR> maybe worth coming up with something<BR><BR>Something I considered, but rejected, back when I thought r001<BR>was the only one, is a runtime switch <A href="mailto:M3@consistentAbort">M3@consistentAbort</A> or<BR>somesuch that will just cleanly exit(0) or exit(1) in these cases,<BR>and not print a callstack. I don't want to foul up the<BR>system TOO much for the sake of testing, but testability<BR>is an expected design goal...<BR><BR>Again, this is an issue across platforms.<BR> LINUXLIBC6 seems to print something slightly differently<BR> every time you run these. Test.common has a gross workaround.<BR> The checked in std* files are from FreeBSD.<BR><BR>e020 unknown so far<BR><BR>e026 was a problem on all platforms and should be ok now;<BR> was a compiler bug, I fixed<BR><BR>e029 unknown so far<BR><BR>I think p209 and p210 are the most important currently.<BR>And then maybe e020, e029.<BR><BR>I expect to be "out" all of Sunday.<BR><BR>The Tinderbox SHOULD be OK now.<BR>Sorry...<BR> <BR><BR> - Jay<BR><BR><BR><BR>
<HR id=EC_EC_EC_stopSpelling>
<BR>> Date: Sun, 4 May 2008 15:30:40 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: [M3devel] Tinderbox tests on NT386<BR>> <BR>> In case anybody wonders about<BR>> <BR>> http://www.opencm3.net/m3tests/m3tests-NT386-2008-05-03-22-37-30.html<BR>> <BR>> and following reports, I'm currently trying to run the m3tests on<BR>> NT386 in an older version to get a usable reference for the current<BR>> problems. There have been so many changes that I'm unable to keep<BR>> up with them, and some things seem to be broken.<BR>> <BR>> Except for the problems in m3tests, the rest of the tinderbox<BR>> regression test framework seems to be working now for regular<BR>> regression tests on Windows XP with Cygwin. Some initialization<BR>> scripts are needed for running them, but that was to be expected.<BR>> <BR>> The m3tests reports for the last two days for all target platforms<BR>> in the tinderbox are not correct (at least, if they show no errors);<BR>> there have been some structural changes and more things need to be<BR>> adapted. Jay Krell is working on it.<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></body>
</html>