[M3devel] release status [was something else]

Tue Mar 16 16:21:41 CET 2010

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.
So, this argues that we hold off on releasing the NT386 64-bit LONGINT support for now.

Thoughts?

On 16 Mar 2010, at 07:21, Jay K wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100316/bb4e5e62/attachment-0002.html>