<html><head><base href="x-msg://740/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ah, yes, one issue about bringing over m3front changes is that it also includes the atomics support. I don't think we want to do this in this release.<div>So, this argues that we hold off on releasing the NT386 64-bit LONGINT support for now.</div><div><br></div><div>Thoughts?<br><div><br>
<br><div><div>On 16 Mar 2010, at 07:21, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">Responding to just parts:<br> <br><br>> > - NT386 has no 64bit longint in release branch. Partly the point of<span class="Apple-converted-space"> </span><br>> > this question.<br>><span class="Apple-converted-space"> </span><br>> I thought Randy was going to do some more testing. If the m3back LONGINT<br>> changes don't break anything else, I'd be for just merging them to the<br> <br> <br>It is a big change.<br>It is dependent on TInt/TWord changes, though that is flexible.<br>I could copy and rename them "M3BackInt".<br>Or we could take them -- they go with m3front changes.<br> <br> <br>Or we could even do a little experiment: The reason I use TInt/TWord<br>is to get 64bit integers portably to 32bit hosts. Previously INTEGER/Word was used.<br>I could try using LONGINT/Long instead.<br> <br> <br>However it is still a large change. There are some other unrelated changes, nothing<br>too significant on its own (I always say), but it adds up:<br>It isn't messed up, but it is maybe "beyond recognition" compared to the previous.<br> (as was recently suggested)<br> <br>some renaming for, I claim, clarity<br> <br>some small optimizations (e.g. using shorter encodings sometimes, like<br> a byte instead of a dword for constants in instructions, or<br>equivalent shorter constructs like or reg,-1 instead of mov reg,-1),<br> <br>atomics support, actually in very good shape now, but could use more testing and optimization<br> <br>"rewrite" of insert/extract to no longer use the tables, I've always<br>been bothered by those tables<br> <br>"rewrite" of set_singleton/set_member to be *much* smaller/faster<br> set_singleton is just the bts instruction, instead of a function call<br> set_member is just bt instruction plus carry flag extraction, instead of a function call<br> <br>cleanup of the way epilogues are sometimes "patched in"<br> <br>Only save/restore non-volatile registers that are actually used.<br> <br>Probably other stuff I'm forgetting.<br> <br>There's also small related changes in m3objfile: support for outputing more than 4<br>bytes at a time, support for "backing up".<br>Some extra commenting.<br>Some formating consistency (then always at end of line, else always on its own line).<br>"Namespace flattening" (from foo import a,b,c).<br> <br>I need to test 64bit subrange checking.<br>The code is a little fishy in that it deals with single registers.<br>It is an optimization and could probably just be pessimized.<br> Or maybe easy to fix.<br> <br> <br>There's also the question as to if the TInt use is all subtely wrong as Tony seems to say.<br>I don't understand yet.<br>It *seems* to work well and it didn't previously pay much attention to types, it<br>just used INTEGER everywhere.<br> <br> <br>The changes are overall large.<br>Diff the two trees, just in m3back.<br> <br> <br>I actually think my earlier question might be the way to go to dramatically<br>increase testing/coverage/confidence -- cm3 -test64 appends "_TEST64"<br>to the build dir name (maybe maybe not the target name) and sets<br>WORD_SIZE = "64" and BITSIZE(INTEGER) and ADDRESS to 64.<br>I'd even consider something "simpler" where I actually create another complete<br>target, I386_NT_TEST64, including the various entries in m3makefiles, Target.i3, etc.<br> <br> <br>Maybe I can just try this locally with a one line change in Target.m3 though.<br>I'll try that first.<br> <br><br>> branch and see if the builds and tests succeed. Of course testing with<br>> some other real applications would be great, but we must not delay<br>> endlessly for that.<br> <br> <br>I have to accept releasing with 32bit LONGINT on NT386, due to the large<br>overall change.<br>Hopefully we arrange for more frequent releases somehow.<br> <br> <br><br>> > - Should maybe improve build/packaging to get NT386-VC80.msi,<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> I'd rather not touch the NT386 setup on our virtual machine;<br><br> <br>I probably won't leave a machine running 24/7.<br>Can I just run the automation manually?<br> Recall Cygwin sshd didn't work adequately at the time.<br> Well, yes, I can always run whatever automation. Somewhat<br> it is a matter of principle of going through the more official more automated<br> process vs. a less official, more error prone, less trusted manual process.<br> <br> <br>Installing additional toolsets on the VM really should work ok, without breaking<br>the existing. Can you try?<br> <br> <br>Maybe this: You create one .msi using the existing process. We'll make<br>sure it is stamped "-VC90" or whatnot.<br>I'll build a whole bunch of others, and they be available as "alternates",<br>and we'll exclude the one corresponding to yours?<br>You provide e.g. cm3-5.8-I386_NT-VC80.msi and I'll provide<br> cm3-5.8-I386_NT-VC20.msi<br> cm3-5.8-I386_NT-VC40.msi<br> cm3-5.8-I386_NT-VC41.msi<br> cm3-5.8-I386_NT-VC42.msi<br> cm3-5.8-I386_NT-VC50.msi<br> cm3-5.8-I386_NT-VC60.msi<br> cm3-5.8-I386_NT-VC70.msi<br> cm3-5.8-I386_NT-VC71.msi<br> <deliberate gap here><br> cm3-5.8-I386_NT-VC90.msi<br> <br> <br>I realize some of these are quite old and out of use, but it's pretty simple to produce<br>them all.<br> <br><br> > > - I believe there is "new" divergence in m3front between head and <br> > Is this relevant for the release? Or can we just ignore it?<br><br>I'd have to look, or Tony should say.<br>To some extent it is tied with if we take NT386 64bit longint.<br><br> <br> > msi<br> > We still need to add them to the WWW export/display, don't we?<br><br> <br>Definitely.<br> <br> <br>Sorry of this isn't edited well..took a while already...<br> <br> <br> - Jay<br> <br></div></span></blockquote></div><br></div></div></body></html>