[M3devel] release status [was something else]

[Jay K]

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/d08175b4/attachment-0002.html>