<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Responding to just parts:<BR>
<BR>
<BR>> > - NT386 has no 64bit longint in release branch. Partly the point of <BR>> > this question.<BR>> <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, <BR>> <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> </body>
</html>