[M3commit] LONGINT used by m3quake/cm3 packages

[Tony Hosking]

On 15 Jan 2010, at 18:50, Jay K wrote:

> 
> Interesting. Can the new values be added "at the end" to remain compatible, or they must be inserted where they are? Well, granted, it was already done, so it's hard to be compatible with old and older.

Not easily.

> Even so, if you use an old compiler and its old libraries to build new compiler (but not its libraries), and then new compiler to rebuild libraries and compiler... isn't that ok?

By old, you mean pre-LONGINT, right?

> One of us seems confused. I'm not sure who.

Not me!  ;-)

> Again, old pre-LONGINT compiler can be used to build the current system in a way that we have plenty well enough automated. We first build "up to cm3", skipping libm3/m3core, then clean all and rebuild all with that new cm3.
> 5.2.6 works.
> 5.1.3a does not, I believe because sysutils needs a newer m3core. That could be fixed.
> 
> 
> I realize that it is grey and not clear how far to run this race.
> You go far enough back, you hit transitions, like m3front being written in C and generatin C, you go further back and you write a C compiler in assembly, keep going and you edit the assembler into memory with switches or somesuch..
> 
> 
> One metric has been that you can build with the previous "release".
> I'm not sure which that is.
> 
> 
> 
> - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:51:47 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>> 
>> 
>> 
>> It's not the presence of LONGINT in the libraries or not. It is the presence of changes type type-map information (see RTTipe and its correspondence with TipeMap) which mean that the new libraries are incompatible with old compilers.
>> 
>> 
>> 
>> On 15 Jan 2010, at 17:42, Jay K wrote:
>> 
>> The compiler is not very dependent on newer compiler/libraries, until now, that I changed File.T.status().size to LONGINT.
>> 
>> I was just able to upgrade.py from cm3-min-WIN32-NT386-5.2.6 for example. 5.1.3a failed though.
>> (It's still in progress, but far long.)
>> 
>> m3core/libm3 can depend on current compiler, agreed.
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Fri, 15 Jan 2010 17:13:38 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
>> Subject: Re: [M3commit] LONGINT used by m3quake/cm3 packages
>> 
>> Jay, the bootstrapping pain is inherent. The compiler and libraries are bound together. Currently, the old library and new libraries are incompatible with their respective compilers. Both ways.
>> 
>> On 15 Jan 2010, at 16:56, Jay K wrote:
>> 
>> VAL(LONGINT, INTEGER) is fine outside of cm3/m3quake,
>> but I think what I had is the way to go.
>> The bootstrapping pain is otherwise novel.
>> The compiler doesn't otherwise use LONGINT.
>> (My doing that it started using it.)
>> It ought not until after the current release?
>> 
>> 
>> - Jay
>> 
>> 
>>> Date: Fri, 15 Jan 2010 22:51:15 +0000
>>> To: m3commit at elegosoft.com
>>> From: hosking at elego.de
>>> Subject: [M3commit] CVS Update: cm3
>>> 
>>> CVSROOT: /usr/cvs
>>> Changes by: hosking at birch. 10/01/15 22:51:15
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3quake/src/: QCompiler.m3 QScanner.i3 QScanner.m3
>>> 
>>> Log message:
>>> Revert to VAL.
>>> 
>> 
>> 
>>