From dragisha at m3w.org  Fri Oct  1 00:40:17 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 01 Oct 2010 00:40:17 +0200
Subject: [M3devel] Windows... cm3... linking...
In-Reply-To: <1285879260.3196.2.camel@boromir.m3w.org>
References: <1285879260.3196.2.camel@boromir.m3w.org>
Message-ID: <1285886417.3196.5.camel@boromir.m3w.org>

Got through this... phew... :)

As I am using Shining Light OpenSSL-Win32 port, I jad to get through
with options... Pretty obvious except part where if \\ used
in /LIBPATH:, openssl lib compiles and ships but client apps does not -
there is no \ in sight.

Solution is - even when making m3makefile for Win32 - use / as path
separator.

On Thu, 2010-09-30 at 22:41 +0200, Dragi?a Duri? wrote:
> Anybody doing this? What is m3makefile "magic" for it?

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  1 02:23:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 00:23:50 +0000
Subject: [M3devel] Windows... cm3... linking...
In-Reply-To: <1285886417.3196.5.camel@boromir.m3w.org>
References: <1285879260.3196.2.camel@boromir.m3w.org>,
	<1285886417.3196.5.camel@boromir.m3w.org>
Message-ID: <COL101-W4764E31E9BC2F7341C98D1E6690@phx.gbl>


Your original question was very unclear.
 
 - Jay


----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Fri, 1 Oct 2010 00:40:17 +0200
> Subject: Re: [M3devel] Windows... cm3... linking...
>
> Got through this... phew... :)
>
> As I am using Shining Light OpenSSL-Win32 port, I jad to get through
> with options... Pretty obvious except part where if \\ used
> in /LIBPATH:, openssl lib compiles and ships but client apps does not -
> there is no \ in sight.
>
> Solution is - even when making m3makefile for Win32 - use / as path
> separator.
>
> On Thu, 2010-09-30 at 22:41 +0200, Dragi?a Duri? wrote:
> > Anybody doing this? What is m3makefile "magic" for it?
>
> --
> Dragi?a Duri? 
> 		 	   		  

From jay.krell at cornell.edu  Fri Oct  1 12:17:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 10:17:23 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
Message-ID: <COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>


Huh? You mean hack, cross once, unhack?
I want to cross build as a regular occurence. The entire system.
I already do actually. But currently only enough to get cm3.
The problems occur if you try to build the entire system.
? Ok, right, I left one of the hacks in actually.
? Like TEXTs have a 2GB size limit or such.


"Regular" cross builds are normal in other environments these days.


?- Jay

----------------------------------------
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
> From: hosking at cs.purdue.edu
> Date: Thu, 30 Sep 2010 09:42:59 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> Whenever you cross build you should do a subsequent native bootstrap to eliminate those.
>
> On 30 Sep 2010, at 07:14, Jay K wrote:
>
> >
> > So..we can't fully cross build a 64bit target from a 32bit host because some code
> > wants to declare arrays that fill memory, like so that indexing them never fails
> > an overflow check:
> >
> >
> > TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example
> >
> >
> > I'm faced with a few choices:
> > - do nothing
> > - have the front end pin the sizes to its maximum
> > Leading to such code to fail if it actually operates on data larger than 2GB
> > - use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less
> > - use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long",
> > (roughly: "long" suffices instead on most 64bit systems)
> > - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c
> >
> >
> > Extremely similarly btw:
> >
> >
> > TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example
> > TYPE T2 = RECORD a,b,c:T1; END;
> >
> >
> > which is just to say, it isn't just about total array sizes, but also field offsets.
> >
> >
> > (I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...)
> >
> >
> >
> > I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code.
> > e.g. m3front/src/types/Type.i3/Info, and then all its users.
> >
> > Should these types use a different and unsafe form?
> > Do we have a convenient unsafe form?
> >
> > - Jay
> >
>
 		 	   		  

From jay.krell at cornell.edu  Fri Oct  1 12:19:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 10:19:35 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <1285845869.2729.7.camel@boromir.m3w.org>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<1285845869.2729.7.camel@boromir.m3w.org>
Message-ID: <COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>


Really? What technique was employed?
The current system doesn't work as I want. As most other compilers now do.
You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
Right. In the past gcc didn't have such good cross building capabilities.
So that might have helped.
Now it does. Now cm3cg has no problem crossing arbitrarily.
But the cm3 frontend does.
A 32bit cm3 frontend can't handle sizes larger than 4GB.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 30 Sep 2010 13:24:29 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>
> I went this route a decade or so ago... When I was porting pm3 to
> Linux/ALPHA... John Polstra employed same technique later for ezm3...
>
> Standard bootstrap process splits build process at assembly level. For
> Windows it is split at object code level.
>
> What I did was to split it ad GCC "IR" level. that way, 32->64 bit
> crosscompiler was never required.
>
> On Thu, 2010-09-30 at 11:14 +0000, Jay K wrote:
> > So..we can't fully cross build a 64bit target from a 32bit host
> > because some code
> > wants to declare arrays that fill memory, like so that indexing them
> > never fails
> > an overflow check:
> >
> >
> >
> --
> Dragi?a Duri? 
>
 		 	   		  

From wagner at elegosoft.com  Fri Oct  1 12:37:23 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Oct 2010 12:37:23 +0200
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<1285845869.2729.7.camel@boromir.m3w.org>
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>
Message-ID: <20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>
> Really? What technique was employed?
> The current system doesn't work as I want. As most other compilers now do.
> You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
> Right. In the past gcc didn't have such good cross building capabilities.
> So that might have helped.
> Now it does. Now cm3cg has no problem crossing arbitrarily.
> But the cm3 frontend does.
> A 32bit cm3 frontend can't handle sizes larger than 4GB.

Is this really still such an important problem?
We can easily support cross-builds from all 32 bit targets to all
32 bit targets and from 64 bit targets to both 32 and 64 bit targets,
right?

And we do have several 64 bit build machines...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Oct  1 12:46:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 10:46:12 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>, ,
	<1285845869.2729.7.camel@boromir.m3w.org>,
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>,
	<20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
Message-ID: <COL101-W354E7D14E90E16D1BA3F77E6690@phx.gbl>


No, it isn't a big problem, but it is an obvious wart. I'd like to fix it. I know how. It is just "a bit" tedious.
It is common these days to support arbitrary crosses.
I think we should.

However, granted, gcc uses a mix of:
? 64bit long (for 64bit host targeting 64bit)
? 64bit long long (32bit host targeting 64bit) -- easy, esp. in C where long => long long conversion is automatic (given that it is lossless, no problem, imho, but I lost that argument here, meanwhile, most code in the world is written this way and nobody complains...) 
? "double_int" a struct containing two longs (I don't know why they still use this, maybe support 32bit host targeting 64bit without a 64bit long long?)
? gmp -- arbitrary precision (ditto) 

If we "just" use LONGINT more instead of INTEGER, we can get by with less change.
The "more honest" approach is to use Target.Int though.

I'd like to take a stab at it, but I expect it might be invasive, want to make sure it is ok.

?- Jay

----------------------------------------
> Date: Fri, 1 Oct 2010 12:37:23 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>
> Quoting Jay K :
>
> >
> > Really? What technique was employed?
> > The current system doesn't work as I want. As most other compilers now do.
> > You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
> > Right. In the past gcc didn't have such good cross building capabilities.
> > So that might have helped.
> > Now it does. Now cm3cg has no problem crossing arbitrarily.
> > But the cm3 frontend does.
> > A 32bit cm3 frontend can't handle sizes larger than 4GB.
>
> Is this really still such an important problem?
> We can easily support cross-builds from all 32 bit targets to all
> 32 bit targets and from 64 bit targets to both 32 and 64 bit targets,
> right?
>
> And we do have several 64 bit build machines...
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  1 13:17:16 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 01 Oct 2010 13:17:16 +0200
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>
	, <12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
	<COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
Message-ID: <1285931836.14463.20.camel@boromir.m3w.org>

Can we cross-develop on regular basis now?

For example, I would like to develop for Android (what happened with
it?) and just upload packages.

Possible?

On Fri, 2010-10-01 at 10:17 +0000, Jay K wrote:
> Huh? You mean hack, cross once, unhack?
> I want to cross build as a regular occurence. The entire system.
> I already do actually. But currently only enough to get cm3.
> The problems occur if you try to build the entire system.
>   Ok, right, I left one of the hacks in actually.
>   Like TEXTs have a 2GB size limit or such. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  1 13:30:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 11:30:52 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <1285931836.14463.20.camel@boromir.m3w.org>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,,
	<12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>,
	<COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>,
	<1285931836.14463.20.camel@boromir.m3w.org>
Message-ID: <COL101-W631D593E96E1992F179786E6690@phx.gbl>


Yes and no. For most people's point of view, no.


I regularly cross build just enough to build cm3 -- m3core/libm3/m3quake/cm3/m3middle/m3front/m3linker.


The missing pieces:
? - you can't the entire system, there are a small number of errors
? - What this is doing is getting as far as generating assembly source.
?? Assemble, compiler C (including having C library headers), link C (including having C libraries) are left
? as an exercise, and is of varying difficulty.


If you want to cross to Linux, then it isn't too difficult. But I haven't done it much.
If you want to cross to mingw or cygwin it probably isn't too difficult.
If you want to cross to NetBSD, it probably isn't too difficult.
But all these "isn't too difficult" aren't necessarily the same.


The problem is needing a cross C compiler, cross assembler, cross linker, C libraries and C headers.
A cross C compiler that only generates assembly is as easy as Modula-3 -- use gcc.
Cross assembler and linker can often but not always be GNU binutils.
C libraries and C headers can be glibc or newlib or uclibc, shouldn't be too difficult.
For other systems, you copy /usr/lib and /usr/include.
? I have cross compiled to Solaris from Cygwin for example, and from something (I forgot) to Irix I think.
? I have a cross compiler for alpha-vms on my Mac. But finding the headers/libraries was a bit challenging.


On the other hand, on systems like Fedora, Gentoo, Debian, people are somewhat busy as I understand providing
prebuilt cross toolset packages, apt-get install whatever.


As well for iPhone and Android the "native" toolsets are cross.
So these should be easy.


Android looked a bit daunting to get started with though.
I haven't so much as done hello world in Java or C running in an emulator or on hardware.
If someone can walk me through hello world in C running in an emulator, I'd be in a better position to get Modula-3 there.


I also find anything that involves Eclipse daunting. There are too many to choise from, and while I like
that they have an install-free option, it is nice to have an installer when first starting out.



Now then, there is the question of what should Modula-3 distribution format be?
I think the 3.6 format is a good model to strive for.
Distribute a bunch of assembly files and assemble, compile C, link, on the target.
That equates to "useful to just Jay" becoming more useful.
However Olaf's point is valid. We'd need just one 64bit host to cross build all the 64bit distributions.
And there is other work needed to make this so.
?Mainly some scripting to package stuff up.
? Actually Olaf's "workspace" packages might be close to it. But I really don't like there
? being cm3-ws-web, cm3-ws-games, cm3-ws-comm, etc. Too many. Confusing.
?I want just one cm3-target.tar.gz, and I want the web page to sniff my browser
? and point me at the right one (like Firefox download does). Really, I find our
? download pages very hard to wade through. Huge lists of stuff to download.

Anyway.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 1 Oct 2010 13:17:16 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>
> Can we cross-develop on regular basis now?
>
> For example, I would like to develop for Android (what happened with
> it?) and just upload packages.
>
> Possible?
>
> On Fri, 2010-10-01 at 10:17 +0000, Jay K wrote:
> > Huh? You mean hack, cross once, unhack?
> > I want to cross build as a regular occurence. The entire system.
> > I already do actually. But currently only enough to get cm3.
> > The problems occur if you try to build the entire system.
> > Ok, right, I left one of the hacks in actually.
> > Like TEXTs have a 2GB size limit or such.
> --
> Dragi?a Duri? 
>
 		 	   		  

From hosking at cs.purdue.edu  Fri Oct  1 15:59:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Oct 2010 09:59:22 -0400
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W354E7D14E90E16D1BA3F77E6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>, ,
	<1285845869.2729.7.camel@boromir.m3w.org>,
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>,
	<20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
	<COL101-W354E7D14E90E16D1BA3F77E6690@phx.gbl>
Message-ID: <8EAB461C-8FA1-4D6A-864D-B810029D5561@cs.purdue.edu>

I don't think this should be a priority, especially if invasive...

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 1 Oct 2010, at 06:46, Jay K wrote:

> 
> No, it isn't a big problem, but it is an obvious wart. I'd like to fix it. I know how. It is just "a bit" tedious.
> It is common these days to support arbitrary crosses.
> I think we should.
> 
> However, granted, gcc uses a mix of:
>   64bit long (for 64bit host targeting 64bit)
>   64bit long long (32bit host targeting 64bit) -- easy, esp. in C where long => long long conversion is automatic (given that it is lossless, no problem, imho, but I lost that argument here, meanwhile, most code in the world is written this way and nobody complains...) 
>   "double_int" a struct containing two longs (I don't know why they still use this, maybe support 32bit host targeting 64bit without a 64bit long long?)
>   gmp -- arbitrary precision (ditto) 
> 
> If we "just" use LONGINT more instead of INTEGER, we can get by with less change.
> The "more honest" approach is to use Target.Int though.
> 
> I'd like to take a stab at it, but I expect it might be invasive, want to make sure it is ok.
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Fri, 1 Oct 2010 12:37:23 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>> 
>> Quoting Jay K :
>> 
>>> 
>>> Really? What technique was employed?
>>> The current system doesn't work as I want. As most other compilers now do.
>>> You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
>>> Right. In the past gcc didn't have such good cross building capabilities.
>>> So that might have helped.
>>> Now it does. Now cm3cg has no problem crossing arbitrarily.
>>> But the cm3 frontend does.
>>> A 32bit cm3 frontend can't handle sizes larger than 4GB.
>> 
>> Is this really still such an important problem?
>> We can easily support cross-builds from all 32 bit targets to all
>> 32 bit targets and from 64 bit targets to both 32 and 64 bit targets,
>> right?
>> 
>> And we do have several 64 bit build machines...
>> 
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> 
> 		 	   		  

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

From hosking at cs.purdue.edu  Fri Oct  1 15:58:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Oct 2010 09:58:36 -0400
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
	<COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
Message-ID: <96B9F209-182F-4422-AC77-ED4071EEAF2E@cs.purdue.edu>

What hack?
Why build the entire system in cross?  That seems overly complicated.  Better to just cross-build the compiler.

On 1 Oct 2010, at 06:17, Jay K wrote:

> 
> Huh? You mean hack, cross once, unhack?
> I want to cross build as a regular occurence. The entire system.
> I already do actually. But currently only enough to get cm3.
> The problems occur if you try to build the entire system.
>   Ok, right, I left one of the hacks in actually.
>   Like TEXTs have a 2GB size limit or such.
> 
> 
> "Regular" cross builds are normal in other environments these days.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>> From: hosking at cs.purdue.edu
>> Date: Thu, 30 Sep 2010 09:42:59 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> Whenever you cross build you should do a subsequent native bootstrap to eliminate those.
>> 
>> On 30 Sep 2010, at 07:14, Jay K wrote:
>> 
>>> 
>>> So..we can't fully cross build a 64bit target from a 32bit host because some code
>>> wants to declare arrays that fill memory, like so that indexing them never fails
>>> an overflow check:
>>> 
>>> 
>>> TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example
>>> 
>>> 
>>> I'm faced with a few choices:
>>> - do nothing
>>> - have the front end pin the sizes to its maximum
>>> Leading to such code to fail if it actually operates on data larger than 2GB
>>> - use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less
>>> - use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long",
>>> (roughly: "long" suffices instead on most 64bit systems)
>>> - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c
>>> 
>>> 
>>> Extremely similarly btw:
>>> 
>>> 
>>> TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example
>>> TYPE T2 = RECORD a,b,c:T1; END;
>>> 
>>> 
>>> which is just to say, it isn't just about total array sizes, but also field offsets.
>>> 
>>> 
>>> (I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...)
>>> 
>>> 
>>> 
>>> I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code.
>>> e.g. m3front/src/types/Type.i3/Info, and then all its users.
>>> 
>>> Should these types use a different and unsafe form?
>>> Do we have a convenient unsafe form?
>>> 
>>> - Jay
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Sun Oct  3 09:00:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 07:00:48 +0000
Subject: [M3devel] declare_constant
Message-ID: <COL101-W58C4E09C2D757EA99ABC2FE66B0@phx.gbl>


The frontend never calls declare_constant.
I wonder if it should be removed.
Presumably all constants are embedded in segments.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Sun Oct  3 10:00:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 08:00:07 +0000
Subject: [M3devel] unnecessary temporaries in m3cc/parse.c
Message-ID: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>


I fail to understand why the following need explicit temporaries:

check_nil
check_lo
check_hi
check_range
check_eq
shift
rotate

probably even:
? round
? floor
? ceiling

but floating point doesn't matter so much.

"stabilize_reference" can be used to avoid recomputing values.

?- Jay
 		 	   		  

From dragisha at m3w.org  Sun Oct  3 11:35:01 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 03 Oct 2010 11:35:01 +0200
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20101003073802.D04B02474003@birch.elegosoft.com>
References: <20101003073802.D04B02474003@birch.elegosoft.com>
Message-ID: <1286098501.14463.74.camel@boromir.m3w.org>

new source -> compiling PickleStubs.m3
../src/pickle/ver2/PickleStubs.m3: In function 'PickleStubs_M3':
../src/pickle/ver2/PickleStubs.m3:599:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3542
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
  m3_backend => 4
m3cc (aka cm3cg) failed compiling: PickleStubs.mc


Lots of these, during ./upgrade.sh, from cvshead.

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sun Oct  3 12:57:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 10:57:29 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1286098501.14463.74.camel@boromir.m3w.org>
References: <20101003073802.D04B02474003@birch.elegosoft.com>,
	<1286098501.14463.74.camel@boromir.m3w.org>
Message-ID: <COL101-W62DE90CD685CAA398BEAEFE66B0@phx.gbl>


ok, sorry, I'm still working on it..










----------------------------------------
> From: dragisha at m3w.org
> To: jkrell at elego.de
> Date: Sun, 3 Oct 2010 11:35:01 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> new source -> compiling PickleStubs.m3
> ../src/pickle/ver2/PickleStubs.m3: In function 'PickleStubs_M3':
> ../src/pickle/ver2/PickleStubs.m3:599:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3542
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> m3_backend => 4
> m3cc (aka cm3cg) failed compiling: PickleStubs.mc
>
>
> Lots of these, during ./upgrade.sh, from cvshead.
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Sun Oct  3 14:47:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 12:47:41 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
Message-ID: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>


It appears that due to e.g.


TYPE Pointer = REF Record;
TYPE Record = RECORD
??? Next: Pointer;
END;


it is possible for the backend to get type declarations "out of order".
? There being no "correct" order, no order without forward references.
It says declare_indirect(Pointer) before declare_record(Record).
? I'm not sure of this exact example, but it does occur.


Currently fields are implicitly within the "current" record.


I think in order to break these cycles, declare_field should contain the uid of their record.


And then we should forward declare all records.
Then indirects to them.
Then their fields.


I'm not sure that solves the general case or not though.


More generally we might want to use this pattern also for objects and proctypes.


It's also likely I can solve this in the backend alone, by running more passes
until everything is resolved.


I keep thinking to myself that I might have to build up in memory
a very faithful rendition of the m3cg calls and iterate over it,
before making the gcc trees.


?


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Sun Oct  3 14:51:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 12:51:52 +0000
Subject: [M3devel] subranges 0..-1?
Message-ID: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>


../src/Common/X.i3: In function 'X_I3':
../src/Common/X.i3:4845:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3567


? gcc_assert (min <= max);

? XClientMessageEvent = RECORD
???? type: int;
???? serial: unsigned_long;??? (* # of last request processed by server *)
???? send_event: Bool;???????? (* true if this came from a SendEvent request *)
???? display: DisplayStar;???? (* Display the event was read from *)
???? window: Window;
???? message_type: Atom;
???? format: int;
???? alignment: ARRAY [0..-1] OF long;
???? data: ARRAY [0..MAX (20 * BYTESIZE (char),
????????????????????????? MAX (10 * BYTESIZE (short),
?????????????????????????????? 5 * BYTESIZE (long))) - 1] OF char; END;


???? alignment: ARRAY [0..-1] OF long;


typedef struct {
??? int type;
??? unsigned long serial;??? /* # of last request processed by server */
??? Bool send_event;??? /* true if this came from a SendEvent request */
??? Display *display;??? /* Display the event was read from */
??? Window window;
??? Atom message_type;
??? int format;
??? union {
??? ??? char b[20];
??? ??? short s[10];
??? ??? long l[5];
??? ??? } data;
} XClientMessageEvent;



eh?


I'll remove the assert.
"Clearly"? the Modula-3 should just use an array of long though for the union?


?- Jay

 		 	   		  

From hosking at cs.purdue.edu  Sun Oct  3 23:02:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 3 Oct 2010 17:02:07 -0400
Subject: [M3devel] declare_constant
In-Reply-To: <COL101-W58C4E09C2D757EA99ABC2FE66B0@phx.gbl>
References: <COL101-W58C4E09C2D757EA99ABC2FE66B0@phx.gbl>
Message-ID: <02D443A4-8D02-45E2-B053-37AEFC3A0A92@cs.purdue.edu>

Or perhaps we should be declaring them...

On 3 Oct 2010, at 03:00, Jay K wrote:

> 
> The frontend never calls declare_constant.
> I wonder if it should be removed.
> Presumably all constants are embedded in segments.
> 
>  - Jay
> 
> 
> 
> 
> 		 	   		  



From hosking at cs.purdue.edu  Sun Oct  3 23:05:40 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 3 Oct 2010 17:05:40 -0400
Subject: [M3devel] unnecessary temporaries in m3cc/parse.c
In-Reply-To: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>
References: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>
Message-ID: <6074704E-AF87-43FF-AE7D-361E8A6CD47D@cs.purdue.edu>

Seems reasonable.  The reasons may be lost in the mists of time...

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 3 Oct 2010, at 04:00, Jay K wrote:

> 
> I fail to understand why the following need explicit temporaries:
> 
> check_nil
> check_lo
> check_hi
> check_range
> check_eq
> shift
> rotate
> 
> probably even:
>   round
>   floor
>   ceiling
> 
> but floating point doesn't matter so much.
> 
> "stabilize_reference" can be used to avoid recomputing values.
> 
>  - Jay
> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101003/3192ceeb/attachment.html>

From dragisha at m3w.org  Sun Oct  3 23:30:31 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 03 Oct 2010 23:30:31 +0200
Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
Message-ID: <1286141431.14463.86.camel@boromir.m3w.org>

upgrade.sh works ok, it looks like.. But during make-bin-dist-min cycle
I am seeing those:

new source -> compiling RT0.i3

 declare_pointer: missing type 0xC2DE134C

 replaying to resolve circular types (pass 1)

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Mon Oct  4 01:23:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 23:23:46 +0000
Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
In-Reply-To: <1286141431.14463.86.camel@boromir.m3w.org>
References: <1286141431.14463.86.camel@boromir.m3w.org>
Message-ID: <COL101-W27F6A2E36D944772EDB520E66B0@phx.gbl>


okok I turned them off

?- Jay



----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Sun, 3 Oct 2010 23:30:31 +0200
> Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
>
> upgrade.sh works ok, it looks like.. But during make-bin-dist-min cycle
> I am seeing those:
>
> new source -> compiling RT0.i3
>
> declare_pointer: missing type 0xC2DE134C
>
> replaying to resolve circular types (pass 1)
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 01:30:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 23:30:50 +0000
Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
In-Reply-To: <1286141431.14463.86.camel@boromir.m3w.org>
References: <1286141431.14463.86.camel@boromir.m3w.org>
Message-ID: <COL101-W3644F16E785D059BC978B9E66B0@phx.gbl>


It's great to have someone else trying this stuff!

Thanks,
?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Sun, 3 Oct 2010 23:30:31 +0200
> Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
>
> upgrade.sh works ok, it looks like.. But during make-bin-dist-min cycle
> I am seeing those:
>
> new source -> compiling RT0.i3
>
> declare_pointer: missing type 0xC2DE134C
>
> replaying to resolve circular types (pass 1)
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 01:44:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 23:44:02 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>
Message-ID: <COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>


I think I'll just solve this in the backend by making a few passes.
Maybe something with specific passes where early passes only pay
attention to certain opcodes, that declare types.

The new/current "replay" stuff will maybe go away.

The new/current keeping of the entire file in memory will stay
unless someone has strong evidence/argument that is shouldn't.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: backend interface vs. types vs. forward references?
> Date: Sun, 3 Oct 2010 12:47:41 +0000
>
>
> It appears that due to e.g.
>
>
> TYPE Pointer = REF Record;
> TYPE Record = RECORD
>     Next: Pointer;
> END;
>
>
> it is possible for the backend to get type declarations "out of order".
>   There being no "correct" order, no order without forward references.
> It says declare_indirect(Pointer) before declare_record(Record).
>   I'm not sure of this exact example, but it does occur.
>
>
> Currently fields are implicitly within the "current" record.
>
>
> I think in order to break these cycles, declare_field should contain the uid of their record.
>
>
> And then we should forward declare all records.
> Then indirects to them.
> Then their fields.
>
>
> I'm not sure that solves the general case or not though.
>
>
> More generally we might want to use this pattern also for objects and proctypes.
>
>
> It's also likely I can solve this in the backend alone, by running more passes
> until everything is resolved.
>
>
> I keep thinking to myself that I might have to build up in memory
> a very faithful rendition of the m3cg calls and iterate over it,
> before making the gcc trees.
>
>
> ?
>
>
>  - Jay
>
>
 		 	   		  

From ttmrichter at gmail.com  Mon Oct  4 04:23:37 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Mon, 4 Oct 2010 10:23:37 +0800
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
Message-ID: <AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>

What does an ARRAY [0..-1] OF <anything> actually look like?

On 3 October 2010 20:51, Jay K <jay.krell at cornell.edu> wrote:

>
> ../src/Common/X.i3: In function 'X_I3':
> ../src/Common/X.i3:4845:0: internal compiler error: in
> m3cg_declare_subrange, at m3cg/parse.c:3567
>
>
>   gcc_assert (min <= max);
>
>   XClientMessageEvent = RECORD
>      type: int;
>      serial: unsigned_long;    (* # of last request processed by server *)
>      send_event: Bool;         (* true if this came from a SendEvent
> request *)
>      display: DisplayStar;     (* Display the event was read from *)
>      window: Window;
>      message_type: Atom;
>      format: int;
>      alignment: ARRAY [0..-1] OF long;
>      data: ARRAY [0..MAX (20 * BYTESIZE (char),
>                           MAX (10 * BYTESIZE (short),
>                                5 * BYTESIZE (long))) - 1] OF char; END;
>
>
>      alignment: ARRAY [0..-1] OF long;
>
>
> typedef struct {
>     int type;
>     unsigned long serial;    /* # of last request processed by server */
>     Bool send_event;    /* true if this came from a SendEvent request */
>     Display *display;    /* Display the event was read from */
>     Window window;
>     Atom message_type;
>     int format;
>     union {
>         char b[20];
>         short s[10];
>         long l[5];
>         } data;
> } XClientMessageEvent;
>
>
>
> eh?
>
>
> I'll remove the assert.
> "Clearly"? the Modula-3 should just use an array of long though for the
> union?
>
>
>  - Jay
>
>




-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101004/220b0cd5/attachment.html>

From hosking at cs.purdue.edu  Mon Oct  4 06:08:50 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 00:08:50 -0400
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>
Message-ID: <1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>

It's an array with no elements, since the subrange [0..-1] is empty.

On 3 Oct 2010, at 22:23, Michael Richter wrote:

> What does an ARRAY [0..-1] OF <anything> actually look like?
> 
> On 3 October 2010 20:51, Jay K <jay.krell at cornell.edu> wrote:
> 
> ../src/Common/X.i3: In function 'X_I3':
> ../src/Common/X.i3:4845:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3567
> 
> 
>   gcc_assert (min <= max);
> 
>   XClientMessageEvent = RECORD
>      type: int;
>      serial: unsigned_long;    (* # of last request processed by server *)
>      send_event: Bool;         (* true if this came from a SendEvent request *)
>      display: DisplayStar;     (* Display the event was read from *)
>      window: Window;
>      message_type: Atom;
>      format: int;
>      alignment: ARRAY [0..-1] OF long;
>      data: ARRAY [0..MAX (20 * BYTESIZE (char),
>                           MAX (10 * BYTESIZE (short),
>                                5 * BYTESIZE (long))) - 1] OF char; END;
> 
> 
>      alignment: ARRAY [0..-1] OF long;
> 
> 
> typedef struct {
>     int type;
>     unsigned long serial;    /* # of last request processed by server */
>     Bool send_event;    /* true if this came from a SendEvent request */
>     Display *display;    /* Display the event was read from */
>     Window window;
>     Atom message_type;
>     int format;
>     union {
>         char b[20];
>         short s[10];
>         long l[5];
>         } data;
> } XClientMessageEvent;
> 
> 
> 
> eh?
> 
> 
> I'll remove the assert.
> "Clearly"? the Modula-3 should just use an array of long though for the union?
> 
> 
>  - Jay
> 
>                                          
> 
> 
> 
> -- 
> "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101004/5a819709/attachment.html>

From jay.krell at cornell.edu  Mon Oct  4 12:35:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 10:35:25 +0000
Subject: [M3devel] unnecessary temporaries in m3cc/parse.c
In-Reply-To: <6074704E-AF87-43FF-AE7D-361E8A6CD47D@cs.purdue.edu>
References: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>,
	<6074704E-AF87-43FF-AE7D-361E8A6CD47D@cs.purdue.edu>
Message-ID: <COL101-W4C498D5F36D9300A3A44FE66C0@phx.gbl>


The first bunch are gone now.
The second few are more work and less interesting. Floating point -- meh.
stabilize_reference I sprinkled all around.

?? - Jay

________________________________
> Subject: Re: [M3devel] unnecessary temporaries in m3cc/parse.c
> From: hosking at cs.purdue.edu
> Date: Sun, 3 Oct 2010 17:05:40 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> Seems reasonable. The reasons may be lost in the mists of time...
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 3 Oct 2010, at 04:00, Jay K wrote:
>
>
> I fail to understand why the following need explicit temporaries:
>
> check_nil
> check_lo
> check_hi
> check_range
> check_eq
> shift
> rotate
>
> probably even:
> round
> floor
> ceiling
>
> but floating point doesn't matter so much.
>
> "stabilize_reference" can be used to avoid recomputing values.
>
> - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 12:41:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 10:41:02 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>, ,
	<1285845869.2729.7.camel@boromir.m3w.org>,
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>,
	<20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
Message-ID: <COL101-w65521D7AAC25DB29CD13B6E66C0@phx.gbl>


 > Olaff
 > We can easily support cross-builds from
 > all 32 bit targets to all
 > 32 bit targets and from 64 bit targets to
 > both 32 and 64 bit targets, right?
 
 Correct. 
 Still, I'm very inclined to fix it. 
 Either Target.Int or LONGINT should be used "everywhere". 
 gcc uses long long heavily internally for this purpose,
  if targeting 64bit from 32bit, though
  it also has available "double_int" and gmp.

 - Jay
 		 	   		  

From wagner at elegosoft.com  Mon Oct  4 16:45:46 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 04 Oct 2010 16:45:46 +0200
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>
Message-ID: <20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> I think I'll just solve this in the backend by making a few passes.
> Maybe something with specific passes where early passes only pay
> attention to certain opcodes, that declare types.

I'm not really happy with multiple passes within the backend just to
make gcc happy. The performance of the gcc backend is already poor
compared to an integrated backend and to what M3 should be able to
achieve. How much will it cost wrt. performance?

> The new/current "replay" stuff will maybe go away.

Hm, I must have missed that.

> The new/current keeping of the entire file in memory will stay
> unless someone has strong evidence/argument that is shouldn't.

Keeping the whole (intermediate code) file in memory should be fine,
unless we get problems for large generated files on small machines
somewhere.

How big are the intermediate files for all our own sources?
Can you write out some statistics?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Mon Oct  4 19:03:08 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 17:03:08 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>
Message-ID: <COL101-W63A85230DF18466658F59BE66C0@phx.gbl>


The passes I'm talking about I think will be fast.
True the backend is very slow but I don't think this will matter.
The earlier will passes will ignore most of the data.
The cost will only be in the extra but ignored serialization.
And even then, it might be better -- if the ordering is a certain way
and guaranteed, once it hits certain opcodes, it will know the types
are all done and start over, without walking each opcode one at a time.

I tried building m3cc on virtual machines with only 256MB and it failed.
I had to up to 384 MB. If I cal recall correctly.

Granted, we don't always build m3cc.

Remember that optimized builds would often use "unit at once"
?compilation, so the entire gcc tree would be in memory.
Now, currently, we never do that for Modula-3, because of a bug
where it throws out functions that are needed to be kept.
But for C/C++ it is not unusual (again, including compiling m3cc).
The tree representation is presumably not much different/smaller than
the m3cg representation. For actual C/C++ there might be a bigger difference,
what with comments/whitespace removed.
But from the gcc point of view, Modula-3 source is already in an encoded binary form.
Granted, the strings are duplicatd.

Still, the access pattern remains linear.
So it doesn't increase working set. Just virtual address space requiremens.

This is something I learned reeently working with large data -- linear access
patterns are what is good and keeps working set down, vs. random access.

Plus, the file gets closed which does free a little of resources, though
probably less than are being additional consumed.

?- Jay

----------------------------------------
> Date: Mon, 4 Oct 2010 16:45:46 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> Quoting Jay K :
>
> > I think I'll just solve this in the backend by making a few passes.
> > Maybe something with specific passes where early passes only pay
> > attention to certain opcodes, that declare types.
>
> I'm not really happy with multiple passes within the backend just to
> make gcc happy. The performance of the gcc backend is already poor
> compared to an integrated backend and to what M3 should be able to
> achieve. How much will it cost wrt. performance?
>
> > The new/current "replay" stuff will maybe go away.
>
> Hm, I must have missed that.
>
> > The new/current keeping of the entire file in memory will stay
> > unless someone has strong evidence/argument that is shouldn't.
>
> Keeping the whole (intermediate code) file in memory should be fine,
> unless we get problems for large generated files on small machines
> somewhere.
>
> How big are the intermediate files for all our own sources?
> Can you write out some statistics?
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 19:16:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 17:16:05 +0000
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
Message-ID: <COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>


It worries me somewhat that we allow zero-sized types.
Including TYPE Foo = RECORD END;
It is reassuring to me that C and C++ doesn't have these.
I don't want to think about what they mean.
Do they make sense to others?

C requires a field. C++ adds a dummy one internally, that it can/must try
to optimize away when inheritance is involved but still.


C++ is interested in the property of pointers not being equal, like:

TYPE T1 = RECORD END;
TYPE T2 = RECORD a,b:T1 END;

VAR a:T1;
ADR(a.b) # ADR(a.a.);

But in Modula-3 they would have the same address.
What does it mean to take the address of something that doesn't exist?
Perhaps it isn't allowed?

As well this kind of thing worries me because Modula-3 truly is
mostly trivially isomorphic with C, which means it is easy to imagine
the gcc backend can handle it. This is an exception.
Sure, there probably is a transform to C, it just isn't obvious to me.
(Granted as well, the gcc backend handles Ada, and Pascal,
so it isn't so limited. Ada at least superficially looks like
Modula-3, I was surprised to see.)

?- Jay

________________________________
> Subject: Re: [M3devel] subranges 0..-1?
> From: hosking at cs.purdue.edu
> Date: Mon, 4 Oct 2010 00:08:50 -0400
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: ttmrichter at gmail.com
>
> It's an array with no elements, since the subrange [0..-1] is empty.
>
> On 3 Oct 2010, at 22:23, Michael Richter wrote:
>
> What does an ARRAY [0..-1] OF actually look like?
>
> On 3 October 2010 20:51, Jay K
> > wrote:
>
> ../src/Common/X.i3: In function 'X_I3':
> ../src/Common/X.i3:4845:0: internal compiler error: in
> m3cg_declare_subrange, at m3cg/parse.c:3567
>
>
> gcc_assert (min <= max);
>
> XClientMessageEvent = RECORD
> type: int;
> serial: unsigned_long; (* # of last request processed by server *)
> send_event: Bool; (* true if this came from a SendEvent
> request *)
> display: DisplayStar; (* Display the event was read from *)
> window: Window;
> message_type: Atom;
> format: int;
> alignment: ARRAY [0..-1] OF long;
> data: ARRAY [0..MAX (20 * BYTESIZE (char),
> MAX (10 * BYTESIZE (short),
> 5 * BYTESIZE (long))) - 1] OF char; END;
>
>
> alignment: ARRAY [0..-1] OF long;
>
>
> typedef struct {
> int type;
> unsigned long serial; /* # of last request processed by server */
> Bool send_event; /* true if this came from a SendEvent request */
> Display *display; /* Display the event was read from */
> Window window;
> Atom message_type;
> int format;
> union {
> char b[20];
> short s[10];
> long l[5];
> } data;
> } XClientMessageEvent;
>
>
>
> eh?
>
>
> I'll remove the assert.
> "Clearly"? the Modula-3 should just use an array of long though for the
> union?
>
>
> - Jay
>
>
>
>
>
> --
> "Perhaps people don't believe this, but throughout all of the
> discussions of entering China our focus has really been what's best for
> the Chinese people. It's not been about our revenue or profit or
> whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 19:23:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 17:23:16 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W63A85230DF18466658F59BE66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>
Message-ID: <COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>


ps: gcc has a very large number of passes over its trees, at least when optimizing.
Like tens or 100+.
The Modula-3 frontend also makes a few passes over everything, just a few.
I don't know where the cost is, but I don't expect to add much. We'll see.
I can try to limit it to not even walk the non-type data.
I should see if the frontend reliably front-loads the type data. It seems to.
We could also put in an end-types opcode to? make it easier to notice.
I think we could also address it in the frontend, by introducing
a type forward declaration call.


> > How big are the intermediate files for all our own sources?


A few months ago I took a quick survey.
This is when I grew the buffer fromwhateve it was to 64K.
I couldn't justify larger because so many would fit in 64K.

I lied somewhat about working set.
If you use a small buffer and iterate in place, your working
set can only grow by the size of the buffer.
If you read the entire thing into memory and walk it linearly,
well, the operating system doesn't necessarily know you won't
walk backwards so it'll let your working set grow, only to throw
out the memory later as needed. This is my rough understanding
based on OS principles. As well, using more address space
has a little extra cost, vs. looping over a small buffer multiple times.

We might might might be able to make some optimizations though,
such as having strings be direct pointers into the buffer instead
of copying them out. There is the matter of the terminal nuls though.
And checking that they fit in the buffer.

> > Can you write out some statistics?


Yeah..
I routinely use cm3 -keep, then just -l target/*c


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com; m3devel at elegosoft.com
> Date: Mon, 4 Oct 2010 17:03:08 +0000
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
>
> The passes I'm talking about I think will be fast.
> True the backend is very slow but I don't think this will matter.
> The earlier will passes will ignore most of the data.
> The cost will only be in the extra but ignored serialization.
> And even then, it might be better -- if the ordering is a certain way
> and guaranteed, once it hits certain opcodes, it will know the types
> are all done and start over, without walking each opcode one at a time.
>
> I tried building m3cc on virtual machines with only 256MB and it failed.
> I had to up to 384 MB. If I cal recall correctly.
>
> Granted, we don't always build m3cc.
>
> Remember that optimized builds would often use "unit at once"
>  compilation, so the entire gcc tree would be in memory.
> Now, currently, we never do that for Modula-3, because of a bug
> where it throws out functions that are needed to be kept.
> But for C/C++ it is not unusual (again, including compiling m3cc).
> The tree representation is presumably not much different/smaller than
> the m3cg representation. For actual C/C++ there might be a bigger difference,
> what with comments/whitespace removed.
> But from the gcc point of view, Modula-3 source is already in an encoded binary form.
> Granted, the strings are duplicatd.
>
> Still, the access pattern remains linear.
> So it doesn't increase working set. Just virtual address space requiremens.
>
> This is something I learned reeently working with large data -- linear access
> patterns are what is good and keeps working set down, vs. random access.
>
> Plus, the file gets closed which does free a little of resources, though
> probably less than are being additional consumed.
>
>  - Jay
>
> ----------------------------------------
> > Date: Mon, 4 Oct 2010 16:45:46 +0200
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] backend interface vs. types vs. forward references?
> >
> > Quoting Jay K :
> >
> > > I think I'll just solve this in the backend by making a few passes.
> > > Maybe something with specific passes where early passes only pay
> > > attention to certain opcodes, that declare types.
> >
> > I'm not really happy with multiple passes within the backend just to
> > make gcc happy. The performance of the gcc backend is already poor
> > compared to an integrated backend and to what M3 should be able to
> > achieve. How much will it cost wrt. performance?
> >
> > > The new/current "replay" stuff will maybe go away.
> >
> > Hm, I must have missed that.
> >
> > > The new/current keeping of the entire file in memory will stay
> > > unless someone has strong evidence/argument that is shouldn't.
> >
> > Keeping the whole (intermediate code) file in memory should be fine,
> > unless we get problems for large generated files on small machines
> > somewhere.
> >
> > How big are the intermediate files for all our own sources?
> > Can you write out some statistics?
> >
> > Olaf
> > --
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >
>
 		 	   		  

From hosking at cs.purdue.edu  Mon Oct  4 19:47:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 13:47:12 -0400
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>
Message-ID: <FC69BD7C-9D55-4642-9F44-0BB86D00DEA1@cs.purdue.edu>

Sure, they make sense.  Just like arrays with no elements.  I don't understand your fearfulness, unless it is just C poisoning your thinking.

On 4 Oct 2010, at 13:16, Jay K wrote:

> 
> It worries me somewhat that we allow zero-sized types.
> Including TYPE Foo = RECORD END;
> It is reassuring to me that C and C++ doesn't have these.
> I don't want to think about what they mean.
> Do they make sense to others?
> 
> C requires a field. C++ adds a dummy one internally, that it can/must try
> to optimize away when inheritance is involved but still.
> 
> 
> C++ is interested in the property of pointers not being equal, like:
> 
> TYPE T1 = RECORD END;
> TYPE T2 = RECORD a,b:T1 END;
> 
> VAR a:T1;
> ADR(a.b) # ADR(a.a.);
> 
> But in Modula-3 they would have the same address.
> What does it mean to take the address of something that doesn't exist?
> Perhaps it isn't allowed?
> 
> As well this kind of thing worries me because Modula-3 truly is
> mostly trivially isomorphic with C, which means it is easy to imagine
> the gcc backend can handle it. This is an exception.
> Sure, there probably is a transform to C, it just isn't obvious to me.
> (Granted as well, the gcc backend handles Ada, and Pascal,
> so it isn't so limited. Ada at least superficially looks like
> Modula-3, I was surprised to see.)
> 
>  - Jay
> 
> ________________________________
>> Subject: Re: [M3devel] subranges 0..-1?
>> From: hosking at cs.purdue.edu
>> Date: Mon, 4 Oct 2010 00:08:50 -0400
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: ttmrichter at gmail.com
>> 
>> It's an array with no elements, since the subrange [0..-1] is empty.
>> 
>> On 3 Oct 2010, at 22:23, Michael Richter wrote:
>> 
>> What does an ARRAY [0..-1] OF actually look like?
>> 
>> On 3 October 2010 20:51, Jay K
>>> wrote:
>> 
>> ../src/Common/X.i3: In function 'X_I3':
>> ../src/Common/X.i3:4845:0: internal compiler error: in
>> m3cg_declare_subrange, at m3cg/parse.c:3567
>> 
>> 
>> gcc_assert (min <= max);
>> 
>> XClientMessageEvent = RECORD
>> type: int;
>> serial: unsigned_long; (* # of last request processed by server *)
>> send_event: Bool; (* true if this came from a SendEvent
>> request *)
>> display: DisplayStar; (* Display the event was read from *)
>> window: Window;
>> message_type: Atom;
>> format: int;
>> alignment: ARRAY [0..-1] OF long;
>> data: ARRAY [0..MAX (20 * BYTESIZE (char),
>> MAX (10 * BYTESIZE (short),
>> 5 * BYTESIZE (long))) - 1] OF char; END;
>> 
>> 
>> alignment: ARRAY [0..-1] OF long;
>> 
>> 
>> typedef struct {
>> int type;
>> unsigned long serial; /* # of last request processed by server */
>> Bool send_event; /* true if this came from a SendEvent request */
>> Display *display; /* Display the event was read from */
>> Window window;
>> Atom message_type;
>> int format;
>> union {
>> char b[20];
>> short s[10];
>> long l[5];
>> } data;
>> } XClientMessageEvent;
>> 
>> 
>> 
>> eh?
>> 
>> 
>> I'll remove the assert.
>> "Clearly"? the Modula-3 should just use an array of long though for the
>> union?
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> 
>> --
>> "Perhaps people don't believe this, but throughout all of the
>> discussions of entering China our focus has really been what's best for
>> the Chinese people. It's not been about our revenue or profit or
>> whatnot."
>> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>> 
> 		 	   		  



From hosking at cs.purdue.edu  Mon Oct  4 19:49:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 13:49:51 -0400
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
Message-ID: <13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>

I see no problem walking the IR trees again to fill in the type information.  Can't you make it part of the lowering pass to GIMPLE?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 4 Oct 2010, at 13:23, Jay K wrote:

> 
> ps: gcc has a very large number of passes over its trees, at least when optimizing.
> Like tens or 100+.
> The Modula-3 frontend also makes a few passes over everything, just a few.
> I don't know where the cost is, but I don't expect to add much. We'll see.
> I can try to limit it to not even walk the non-type data.
> I should see if the frontend reliably front-loads the type data. It seems to.
> We could also put in an end-types opcode to  make it easier to notice.
> I think we could also address it in the frontend, by introducing
> a type forward declaration call.
> 
> 
>>> How big are the intermediate files for all our own sources?
> 
> 
> A few months ago I took a quick survey.
> This is when I grew the buffer fromwhateve it was to 64K.
> I couldn't justify larger because so many would fit in 64K.
> 
> I lied somewhat about working set.
> If you use a small buffer and iterate in place, your working
> set can only grow by the size of the buffer.
> If you read the entire thing into memory and walk it linearly,
> well, the operating system doesn't necessarily know you won't
> walk backwards so it'll let your working set grow, only to throw
> out the memory later as needed. This is my rough understanding
> based on OS principles. As well, using more address space
> has a little extra cost, vs. looping over a small buffer multiple times.
> 
> We might might might be able to make some optimizations though,
> such as having strings be direct pointers into the buffer instead
> of copying them out. There is the matter of the terminal nuls though.
> And checking that they fit in the buffer.
> 
>>> Can you write out some statistics?
> 
> 
> Yeah..
> I routinely use cm3 -keep, then just -l target/*c
> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: wagner at elegosoft.com; m3devel at elegosoft.com
>> Date: Mon, 4 Oct 2010 17:03:08 +0000
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> 
>> The passes I'm talking about I think will be fast.
>> True the backend is very slow but I don't think this will matter.
>> The earlier will passes will ignore most of the data.
>> The cost will only be in the extra but ignored serialization.
>> And even then, it might be better -- if the ordering is a certain way
>> and guaranteed, once it hits certain opcodes, it will know the types
>> are all done and start over, without walking each opcode one at a time.
>> 
>> I tried building m3cc on virtual machines with only 256MB and it failed.
>> I had to up to 384 MB. If I cal recall correctly.
>> 
>> Granted, we don't always build m3cc.
>> 
>> Remember that optimized builds would often use "unit at once"
>> compilation, so the entire gcc tree would be in memory.
>> Now, currently, we never do that for Modula-3, because of a bug
>> where it throws out functions that are needed to be kept.
>> But for C/C++ it is not unusual (again, including compiling m3cc).
>> The tree representation is presumably not much different/smaller than
>> the m3cg representation. For actual C/C++ there might be a bigger difference,
>> what with comments/whitespace removed.
>> But from the gcc point of view, Modula-3 source is already in an encoded binary form.
>> Granted, the strings are duplicatd.
>> 
>> Still, the access pattern remains linear.
>> So it doesn't increase working set. Just virtual address space requiremens.
>> 
>> This is something I learned reeently working with large data -- linear access
>> patterns are what is good and keeps working set down, vs. random access.
>> 
>> Plus, the file gets closed which does free a little of resources, though
>> probably less than are being additional consumed.
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> Date: Mon, 4 Oct 2010 16:45:46 +0200
>>> From: wagner at elegosoft.com
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>>> 
>>> Quoting Jay K :
>>> 
>>>> I think I'll just solve this in the backend by making a few passes.
>>>> Maybe something with specific passes where early passes only pay
>>>> attention to certain opcodes, that declare types.
>>> 
>>> I'm not really happy with multiple passes within the backend just to
>>> make gcc happy. The performance of the gcc backend is already poor
>>> compared to an integrated backend and to what M3 should be able to
>>> achieve. How much will it cost wrt. performance?
>>> 
>>>> The new/current "replay" stuff will maybe go away.
>>> 
>>> Hm, I must have missed that.
>>> 
>>>> The new/current keeping of the entire file in memory will stay
>>>> unless someone has strong evidence/argument that is shouldn't.
>>> 
>>> Keeping the whole (intermediate code) file in memory should be fine,
>>> unless we get problems for large generated files on small machines
>>> somewhere.
>>> 
>>> How big are the intermediate files for all our own sources?
>>> Can you write out some statistics?
>>> 
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>> 
>> 
> 		 	   		  

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

From jay.krell at cornell.edu  Mon Oct  4 20:05:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 18:05:57 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>,
	,,<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>,
	, , <20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>, ,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>,
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>,
	<13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>
Message-ID: <COL101-W23F3AFD8BE5D29A26C6E43E66C0@phx.gbl>


I think I understand and I think so.
Rather than lowing to gimple though, it could just be before all that, right?
I mean, walking the gcc trees and converting from "pre-gimple" to "pre-gimple", right?
i.e. not lowering, just transform within same "space"?

What I was talking about though was walking the m3cg opcode IR.
At least the initial type declaration part.

A new m3cg call to just forward declare types might be good too, instead.

?- Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Mon, 4 Oct 2010 13:49:51 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> I see no problem walking the IR trees again to fill in the type
> information. Can't you make it part of the lowering pass to GIMPLE?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 4 Oct 2010, at 13:23, Jay K wrote:
>
>
> ps: gcc has a very large number of passes over its trees, at least when
> optimizing.
> Like tens or 100+.
> The Modula-3 frontend also makes a few passes over everything, just a few.
> I don't know where the cost is, but I don't expect to add much. We'll see.
> I can try to limit it to not even walk the non-type data.
> I should see if the frontend reliably front-loads the type data. It seems to.
> We could also put in an end-types opcode to make it easier to notice.
> I think we could also address it in the frontend, by introducing
> a type forward declaration call.
>
>
> How big are the intermediate files for all our own sources?
>
>
> A few months ago I took a quick survey.
> This is when I grew the buffer fromwhateve it was to 64K.
> I couldn't justify larger because so many would fit in 64K.
>
> I lied somewhat about working set.
> If you use a small buffer and iterate in place, your working
> set can only grow by the size of the buffer.
> If you read the entire thing into memory and walk it linearly,
> well, the operating system doesn't necessarily know you won't
> walk backwards so it'll let your working set grow, only to throw
> out the memory later as needed. This is my rough understanding
> based on OS principles. As well, using more address space
> has a little extra cost, vs. looping over a small buffer multiple times.
>
> We might might might be able to make some optimizations though,
> such as having strings be direct pointers into the buffer instead
> of copying them out. There is the matter of the terminal nuls though.
> And checking that they fit in the buffer.
>
> Can you write out some statistics?
>
>
> Yeah..
> I routinely use cm3 -keep, then just -l target/*c
>
>
> - Jay
>
> ----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com;
> m3devel at elegosoft.com
> Date: Mon, 4 Oct 2010 17:03:08 +0000
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
>
> The passes I'm talking about I think will be fast.
> True the backend is very slow but I don't think this will matter.
> The earlier will passes will ignore most of the data.
> The cost will only be in the extra but ignored serialization.
> And even then, it might be better -- if the ordering is a certain way
> and guaranteed, once it hits certain opcodes, it will know the types
> are all done and start over, without walking each opcode one at a time.
>
> I tried building m3cc on virtual machines with only 256MB and it failed.
> I had to up to 384 MB. If I cal recall correctly.
>
> Granted, we don't always build m3cc.
>
> Remember that optimized builds would often use "unit at once"
> compilation, so the entire gcc tree would be in memory.
> Now, currently, we never do that for Modula-3, because of a bug
> where it throws out functions that are needed to be kept.
> But for C/C++ it is not unusual (again, including compiling m3cc).
> The tree representation is presumably not much different/smaller than
> the m3cg representation. For actual C/C++ there might be a bigger difference,
> what with comments/whitespace removed.
> But from the gcc point of view, Modula-3 source is already in an
> encoded binary form.
> Granted, the strings are duplicatd.
>
> Still, the access pattern remains linear.
> So it doesn't increase working set. Just virtual address space requiremens.
>
> This is something I learned reeently working with large data -- linear access
> patterns are what is good and keeps working set down, vs. random access.
>
> Plus, the file gets closed which does free a little of resources, though
> probably less than are being additional consumed.
>
> - Jay
>
> ----------------------------------------
> Date: Mon, 4 Oct 2010 16:45:46 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> Quoting Jay K :
>
> I think I'll just solve this in the backend by making a few passes.
> Maybe something with specific passes where early passes only pay
> attention to certain opcodes, that declare types.
>
> I'm not really happy with multiple passes within the backend just to
> make gcc happy. The performance of the gcc backend is already poor
> compared to an integrated backend and to what M3 should be able to
> achieve. How much will it cost wrt. performance?
>
> The new/current "replay" stuff will maybe go away.
>
> Hm, I must have missed that.
>
> The new/current keeping of the entire file in memory will stay
> unless someone has strong evidence/argument that is shouldn't.
>
> Keeping the whole (intermediate code) file in memory should be fine,
> unless we get problems for large generated files on small machines
> somewhere.
>
> How big are the intermediate files for all our own sources?
> Can you write out some statistics?
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>
>
>
 		 	   		  

From mika at async.async.caltech.edu  Mon Oct  4 20:12:08 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 04 Oct 2010 11:12:08 -0700
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W481C04C97A03C69858A03BE66C0@phx.gbl> 
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>
Message-ID: <20101004181208.154661A208C@async.async.caltech.edu>

Jay K writes:
>
>It worries me somewhat that we allow zero-sized types.
>Including TYPE Foo =3D RECORD END=3B
>It is reassuring to me that C and C++ doesn't have these.
>I don't want to think about what they mean.
>Do they make sense to others?

Yes, they make a lot of sense.  Not having them means special-casing
any program that generates code.  Obviously a correct program that generates
code including a zero-sized array will never generate an expression
that indexes such an array...

>
>C requires a field. C++ adds a dummy one internally=2C that it can/must try
>to optimize away when inheritance is involved but still.
>
>
>C++ is interested in the property of pointers not being equal=2C like:
>
>TYPE T1 =3D RECORD END=3B
>TYPE T2 =3D RECORD a=2Cb:T1 END=3B
>
>VAR a:T1=3B
>ADR(a.b) # ADR(a.a.)=3B
>
>But in Modula-3 they would have the same address.
>What does it mean to take the address of something that doesn't exist?
>Perhaps it isn't allowed?

This is UNSAFE code, so it means whatever the implementation makes
it mean, including (as far as I'm concerned) a compiler crash, if
that is the easiest thing you can make it mean.  I really wouldn't
worry about the UNSAFE parts of Modula-3 that much...  expected to be
implementation-dependent.  Although I admit it would be better to have
it do something meaningless in this case.  Since T1 is an empty type
there's not much you can do with the address anyhow.

    Mika


From jay.krell at cornell.edu  Mon Oct  4 20:30:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 18:30:31 +0000
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <20101004181208.154661A208C@async.async.caltech.edu>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>,
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>, ,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>,
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>,
	<20101004181208.154661A208C@async.async.caltech.edu>
Message-ID: <COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>


So, I'm not supposed to worry about unsafe stuff..including if the backend and debugging information can? handle it? No.
Unsafe code matters, a lot.

?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> Date: Mon, 4 Oct 2010 11:12:08 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] subranges 0..-1?
>
> Jay K writes:
> >
> >It worries me somewhat that we allow zero-sized types.
> >Including TYPE Foo =3D RECORD END=3B
> >It is reassuring to me that C and C++ doesn't have these.
> >I don't want to think about what they mean.
> >Do they make sense to others?
>
> Yes, they make a lot of sense. Not having them means special-casing
> any program that generates code. Obviously a correct program that generates
> code including a zero-sized array will never generate an expression
> that indexes such an array...
>
> >
> >C requires a field. C++ adds a dummy one internally=2C that it can/must try
> >to optimize away when inheritance is involved but still.
> >
> >
> >C++ is interested in the property of pointers not being equal=2C like:
> >
> >TYPE T1 =3D RECORD END=3B
> >TYPE T2 =3D RECORD a=2Cb:T1 END=3B
> >
> >VAR a:T1=3B
> >ADR(a.b) # ADR(a.a.)=3B
> >
> >But in Modula-3 they would have the same address.
> >What does it mean to take the address of something that doesn't exist?
> >Perhaps it isn't allowed?
>
> This is UNSAFE code, so it means whatever the implementation makes
> it mean, including (as far as I'm concerned) a compiler crash, if
> that is the easiest thing you can make it mean. I really wouldn't
> worry about the UNSAFE parts of Modula-3 that much... expected to be
> implementation-dependent. Although I admit it would be better to have
> it do something meaningless in this case. Since T1 is an empty type
> there's not much you can do with the address anyhow.
>
> Mika
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 21:02:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 19:02:02 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>,
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
Message-ID: <COL101-W3436C5D1E0DEEAD71F2C9FE66C0@phx.gbl>


> ps: gcc has a very large number of passes over its trees, at least when optimizing.

according to the documentation, there
are around 100 SSA form optimization passes and 70 RTL optimization passes
-O2 and -O3 are noticably slower than -O0.
? (and -enable-checking=all is much slower again, and we do still have problems there..)

Bing for "gcc internal passes" and you should find it.

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon Oct  4 22:39:57 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 16:39:57 -0400
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>,
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>, ,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>,
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>,
	<20101004181208.154661A208C@async.async.caltech.edu>
	<COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>
Message-ID: <38B55395-49EA-4B95-BB16-C2A08C279BA5@cs.purdue.edu>

How does the backend handle empty Pascal records?

On 4 Oct 2010, at 14:30, Jay K wrote:

> 
> So, I'm not supposed to worry about unsafe stuff..including if the backend and debugging information can  handle it? No.
> Unsafe code matters, a lot.
> 
>  - Jay
> 
> ----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Mon, 4 Oct 2010 11:12:08 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] subranges 0..-1?
>> 
>> Jay K writes:
>>> 
>>> It worries me somewhat that we allow zero-sized types.
>>> Including TYPE Foo =3D RECORD END=3B
>>> It is reassuring to me that C and C++ doesn't have these.
>>> I don't want to think about what they mean.
>>> Do they make sense to others?
>> 
>> Yes, they make a lot of sense. Not having them means special-casing
>> any program that generates code. Obviously a correct program that generates
>> code including a zero-sized array will never generate an expression
>> that indexes such an array...
>> 
>>> 
>>> C requires a field. C++ adds a dummy one internally=2C that it can/must try
>>> to optimize away when inheritance is involved but still.
>>> 
>>> 
>>> C++ is interested in the property of pointers not being equal=2C like:
>>> 
>>> TYPE T1 =3D RECORD END=3B
>>> TYPE T2 =3D RECORD a=2Cb:T1 END=3B
>>> 
>>> VAR a:T1=3B
>>> ADR(a.b) # ADR(a.a.)=3B
>>> 
>>> But in Modula-3 they would have the same address.
>>> What does it mean to take the address of something that doesn't exist?
>>> Perhaps it isn't allowed?
>> 
>> This is UNSAFE code, so it means whatever the implementation makes
>> it mean, including (as far as I'm concerned) a compiler crash, if
>> that is the easiest thing you can make it mean. I really wouldn't
>> worry about the UNSAFE parts of Modula-3 that much... expected to be
>> implementation-dependent. Although I admit it would be better to have
>> it do something meaningless in this case. Since T1 is an empty type
>> there's not much you can do with the address anyhow.
>> 
>> Mika
> 		 	   		  



From hosking at cs.purdue.edu  Mon Oct  4 22:41:35 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 16:41:35 -0400
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W23F3AFD8BE5D29A26C6E43E66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, , ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, , ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>, ,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>,
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>,
	<13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>
	<COL101-W23F3AFD8BE5D29A26C6E43E66C0@phx.gbl>
Message-ID: <0B6701D7-46BE-458D-8B25-34D2ABD35D77@cs.purdue.edu>

I would avoid a new m3cg.  Just walk the tree as you say.

On 4 Oct 2010, at 14:05, Jay K wrote:

> 
> I think I understand and I think so.
> Rather than lowing to gimple though, it could just be before all that, right?
> I mean, walking the gcc trees and converting from "pre-gimple" to "pre-gimple", right?
> i.e. not lowering, just transform within same "space"?
> 
> What I was talking about though was walking the m3cg opcode IR.
> At least the initial type declaration part.
> 
> A new m3cg call to just forward declare types might be good too, instead.
> 
>  - Jay
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Mon, 4 Oct 2010 13:49:51 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> I see no problem walking the IR trees again to fill in the type
>> information. Can't you make it part of the lowering pass to GIMPLE?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> On 4 Oct 2010, at 13:23, Jay K wrote:
>> 
>> 
>> ps: gcc has a very large number of passes over its trees, at least when
>> optimizing.
>> Like tens or 100+.
>> The Modula-3 frontend also makes a few passes over everything, just a few.
>> I don't know where the cost is, but I don't expect to add much. We'll see.
>> I can try to limit it to not even walk the non-type data.
>> I should see if the frontend reliably front-loads the type data. It seems to.
>> We could also put in an end-types opcode to make it easier to notice.
>> I think we could also address it in the frontend, by introducing
>> a type forward declaration call.
>> 
>> 
>> How big are the intermediate files for all our own sources?
>> 
>> 
>> A few months ago I took a quick survey.
>> This is when I grew the buffer fromwhateve it was to 64K.
>> I couldn't justify larger because so many would fit in 64K.
>> 
>> I lied somewhat about working set.
>> If you use a small buffer and iterate in place, your working
>> set can only grow by the size of the buffer.
>> If you read the entire thing into memory and walk it linearly,
>> well, the operating system doesn't necessarily know you won't
>> walk backwards so it'll let your working set grow, only to throw
>> out the memory later as needed. This is my rough understanding
>> based on OS principles. As well, using more address space
>> has a little extra cost, vs. looping over a small buffer multiple times.
>> 
>> We might might might be able to make some optimizations though,
>> such as having strings be direct pointers into the buffer instead
>> of copying them out. There is the matter of the terminal nuls though.
>> And checking that they fit in the buffer.
>> 
>> Can you write out some statistics?
>> 
>> 
>> Yeah..
>> I routinely use cm3 -keep, then just -l target/*c
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: wagner at elegosoft.com;
>> m3devel at elegosoft.com
>> Date: Mon, 4 Oct 2010 17:03:08 +0000
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> 
>> The passes I'm talking about I think will be fast.
>> True the backend is very slow but I don't think this will matter.
>> The earlier will passes will ignore most of the data.
>> The cost will only be in the extra but ignored serialization.
>> And even then, it might be better -- if the ordering is a certain way
>> and guaranteed, once it hits certain opcodes, it will know the types
>> are all done and start over, without walking each opcode one at a time.
>> 
>> I tried building m3cc on virtual machines with only 256MB and it failed.
>> I had to up to 384 MB. If I cal recall correctly.
>> 
>> Granted, we don't always build m3cc.
>> 
>> Remember that optimized builds would often use "unit at once"
>> compilation, so the entire gcc tree would be in memory.
>> Now, currently, we never do that for Modula-3, because of a bug
>> where it throws out functions that are needed to be kept.
>> But for C/C++ it is not unusual (again, including compiling m3cc).
>> The tree representation is presumably not much different/smaller than
>> the m3cg representation. For actual C/C++ there might be a bigger difference,
>> what with comments/whitespace removed.
>> But from the gcc point of view, Modula-3 source is already in an
>> encoded binary form.
>> Granted, the strings are duplicatd.
>> 
>> Still, the access pattern remains linear.
>> So it doesn't increase working set. Just virtual address space requiremens.
>> 
>> This is something I learned reeently working with large data -- linear access
>> patterns are what is good and keeps working set down, vs. random access.
>> 
>> Plus, the file gets closed which does free a little of resources, though
>> probably less than are being additional consumed.
>> 
>> - Jay
>> 
>> ----------------------------------------
>> Date: Mon, 4 Oct 2010 16:45:46 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> Quoting Jay K :
>> 
>> I think I'll just solve this in the backend by making a few passes.
>> Maybe something with specific passes where early passes only pay
>> attention to certain opcodes, that declare types.
>> 
>> I'm not really happy with multiple passes within the backend just to
>> make gcc happy. The performance of the gcc backend is already poor
>> compared to an integrated backend and to what M3 should be able to
>> achieve. How much will it cost wrt. performance?
>> 
>> The new/current "replay" stuff will maybe go away.
>> 
>> Hm, I must have missed that.
>> 
>> The new/current keeping of the entire file in memory will stay
>> unless someone has strong evidence/argument that is shouldn't.
>> 
>> Keeping the whole (intermediate code) file in memory should be fine,
>> unless we get problems for large generated files on small machines
>> somewhere.
>> 
>> How big are the intermediate files for all our own sources?
>> Can you write out some statistics?
>> 
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> 
>> 
>> 
>> 
> 		 	   		  



From mika at async.async.caltech.edu  Mon Oct  4 23:16:27 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 04 Oct 2010 14:16:27 -0700
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W169957CE63F370DBAF099FE66C0@phx.gbl> 
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>,
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>, ,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>,
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>,
	<20101004181208.154661A208C@async.async.caltech.edu>
	<COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>
Message-ID: <20101004211627.935681A208C@async.async.caltech.edu>

Of course unsafe code matters.

But does the particular example of unsafe code (ADR of a zero-sized
object) matter?  No, because:

1. For human-written code we use your argument.  "Don't do that"

2. Don't generate UNSAFE code by machine.  Or if you must be as careful
   as implied by 1.

     Mika

Jay K writes:
>
>So=2C I'm not supposed to worry about unsafe stuff..including if the backen=
>d and debugging information can=A0 handle it? No.
>Unsafe code matters=2C a lot.
>
>=A0- Jay
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Mon=2C 4 Oct 2010 11:12:08 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] subranges 0..-1?
>>
>> Jay K writes:
>> >
>> >It worries me somewhat that we allow zero-sized types.
>> >Including TYPE Foo =3D3D RECORD END=3D3B
>> >It is reassuring to me that C and C++ doesn't have these.
>> >I don't want to think about what they mean.
>> >Do they make sense to others?
>>
>> Yes=2C they make a lot of sense. Not having them means special-casing
>> any program that generates code. Obviously a correct program that generat=
>es
>> code including a zero-sized array will never generate an expression
>> that indexes such an array...
>>
>> >
>> >C requires a field. C++ adds a dummy one internally=3D2C that it can/mus=
>t try
>> >to optimize away when inheritance is involved but still.
>> >
>> >
>> >C++ is interested in the property of pointers not being equal=3D2C like:
>> >
>> >TYPE T1 =3D3D RECORD END=3D3B
>> >TYPE T2 =3D3D RECORD a=3D2Cb:T1 END=3D3B
>> >
>> >VAR a:T1=3D3B
>> >ADR(a.b) # ADR(a.a.)=3D3B
>> >
>> >But in Modula-3 they would have the same address.
>> >What does it mean to take the address of something that doesn't exist?
>> >Perhaps it isn't allowed?
>>
>> This is UNSAFE code=2C so it means whatever the implementation makes
>> it mean=2C including (as far as I'm concerned) a compiler crash=2C if
>> that is the easiest thing you can make it mean. I really wouldn't
>> worry about the UNSAFE parts of Modula-3 that much... expected to be
>> implementation-dependent. Although I admit it would be better to have
>> it do something meaningless in this case. Since T1 is an empty type
>> there's not much you can do with the address anyhow.
>>
>> Mika
> 		 	   		  =


From jay.krell at cornell.edu  Tue Oct  5 11:00:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 09:00:40 +0000
Subject: [M3devel] hardware clearance?
Message-ID: <COL101-W32FCFBBE44FBF546E07C71E66D0@phx.gbl>


Hey folks.
I have an impending possible need to drastically rapidly cleanup my place.
One of the biggest steps I can take is getting rid of hardware.


Anyone interested?
For free?


It is a quite a mix.? All from eBay over past 2 or so years.
Much has been seen to work, a little has been seen not work, some
has never been tried. Many have not been powered on for months/years.
All have at least some memory/hard drive, some have optical drive,
?or some I'd use external SCSI CD-ROM drive.


SPARC64, PPC64 IA64, PPC, Alpha, MIPS. Stuff capable
of running AIX, Irix, HP-UX, AMD64, VMS, Tru64, Linux,
OpenBSD, FreeBSD, NetBSD, Solaris.

Laptops I can keep.


SPARC64:
? 3x: have run Linux, OpenBSD, Solaris a while
? includes two Hudson nodes (Linux, Solaris, not OpenBSD)
? could also surely run NetBSD, FreeBSD
? at least 4 machines, not all of which have been used 
? both "workstation" and 1U form factors 
? 
? 
MIPS/SGI:
?3 x O2 and 2 x Fuel (much faster)
?? 2 x O2 never used, or 1x might be broken
?? (when I tried to install Linux or NetBSD
?? on an O2, it powered off and would never power
?? back on; OpenBSD proved easier to install) 
?O2 running OpenBSD, used to run Irix
?? should also be viable for NetBSD, Linux
?Fuel running Irix, could also run OpenBSD
?Fuel is much much faster.
?Irix you can bootstrap up to gcc by using some
? seemingly accidentally there C compiler. 

?
IA64:
?2x; was able to run Linux (Debian) on both.
?Probably viable for VMS, HP-UX, FreeBSD,
?? though I attempted HP-UX and FreeBSD, no luck.
?I might keep one of these.
?One of them lacks video out, must install over serial console.
I think 2U form factors (certainly boxy); heavy 


HPPA:
? one machine, was able to run Linux and HP-UX on it
? no video out, must install over serial console
? 1U or 2U 
? HP-UX can be bootstrapped up to current gcc using in-box K&R cc (via gcc 3.x).


AMD64:
?one Sun workstation, some decent specs


PPC64:
?iMac G5, running Darwin, should be viable for others (e.g. Linux)
?
?
PPC64:
? IBM pSeries workstation; running AIX 5.3, should be viable for others (e.g. Linux)
? This machine seemed to overheat and poweroff, e.g. when building gcc, but
? I did manage to get it working pretty well.


Alpha:
?3x or 4x.
?I only ever tried to use one of them and it didn't seem to work.
?2 are "workstation" size, 2 are the nicer smaller DS10L.


68K/Mac:
? 2x that I don't anticipate anything happening with.
? 
? 
I can also probably spare some Mac/PPC laptops.
? One of which is broken.
? 

I'd rather not lose too much on shipping. But flexible.
I'd rather ship as much as possible to same place. But flexible.
I'd rather reserve right of return, in case I get more space and time,
? but the odds of this mattering is generally decreasing.
? 

Rather than wiping and pulling hard drives, I'll probably just
change SSH keys.


Thanks and sorry of this is off-topic.
?- Jay




 		 	   		  

From wagner at elegosoft.com  Tue Oct  5 12:35:45 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 05 Oct 2010 12:35:45 +0200
Subject: [M3devel] compilation failure on Solaris
Message-ID: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>

There are segmentation faults during compilation of Lex.m3, see:

http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console

=== package m3-libs/libm3 ===
  +++ cm3 -build  
-DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS  && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'   
+++
../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
   m3_backend => 4
m3cc (aka cm3cg) failed compiling: Lex.mc
../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
   m3_backend => 4
m3cc (aka cm3cg) failed compiling: FmtBuf.mc

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From dragisha at m3w.org  Tue Oct  5 15:32:30 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 05 Oct 2010 15:32:30 +0200
Subject: [M3devel] m3gap.... what is it and what does this mean?
Message-ID: <1286285550.3514.20.camel@boromir.m3w.org>

(gdb) p event
$1 = {type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 = 
    {<No data fields>}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {<No data fields>}, 
  string = 0xa <Address 0xa out of bounds>, hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {<No data fields>}}


 VAR
   event: Gdk.EventKey;

  EventKey = RECORD 
    type: EventType;
    window: WindowStar;
    send_event: char;
    time: unsigned_long_int;  
    state: unsigned_int;
    keyval: unsigned_int;
    length: int;
    string: char_star;
    hardware_keycode: unsigned_short_int;
    group: unsigned_char;
  END;

also with m3gdb....

(m3gdb) p event
$1 = {4type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x0,
send_event = 0 '\000', 
  _m3gap_136_56 = {<No data fields>}, time = 49, state = -937844736,
keyval = 32616, length = 23801648, 
  _m3gap_352_32 = {<No data fields>}, string = 0x7f68c839be10 "\001
\000", hardware_keycode = 0, group = 0 '\000', 
  _m3gap_472_40 = {<No data fields>}}

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Tue Oct  5 16:48:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 14:48:41 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286285550.3514.20.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>
Message-ID: <COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>


Hey, look, until August, stock gdb never showed any fields!

The front does layout, it might tell the backend:

struct {
? integer a at offset 4, size 4
? integer b at offset 12, size 4
}

in which case the backend will generate a "gap" field at offset 8, size 4

I suspect we might not have to generate the fields.
I'm nervous that the backend might do its own layout and move up b to offset 8 otherwise.
And there was other code in the backing doing similar.

We are in complete control of the name.
If you want we can call it "_m3_padding_for_alignment"
or "-m3_nothing_to_see_here"
or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)

?- Jay




----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Tue, 5 Oct 2010 15:32:30 +0200
> Subject: [M3devel] m3gap.... what is it and what does this mean?
>
> (gdb) p event
> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 =
> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {},
> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>
>
> VAR
> event: Gdk.EventKey;
>
> EventKey = RECORD
> type: EventType;
> window: WindowStar;
> send_event: char;
> time: unsigned_long_int;
> state: unsigned_int;
> keyval: unsigned_int;
> length: int;
> string: char_star;
> hardware_keycode: unsigned_short_int;
> group: unsigned_char;
> END;
>
> also with m3gdb....
>
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> send_event = 0 '\000',
> _m3gap_136_56 = {}, time = 49, state = -937844736,
> keyval = 32616, length = 23801648,
> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
> \000", hardware_keycode = 0, group = 0 '\000',
> _m3gap_472_40 = {}}
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From rodney_bates at lcwb.coop  Tue Oct  5 21:26:41 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 05 Oct 2010 14:26:41 -0500
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	<COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>
Message-ID: <4CAB7BF1.3050801@lcwb.coop>



Jay K wrote:
> Hey, look, until August, stock gdb never showed any fields!
> 
> The front does layout, it might tell the backend:
> 
> struct {
>   integer a at offset 4, size 4
>   integer b at offset 12, size 4
> }
> 
> in which case the backend will generate a "gap" field at offset 8, size 4
> 
> I suspect we might not have to generate the fields.
> I'm nervous that the backend might do its own layout and move up b to offset 8 otherwise.
> And there was other code in the backing doing similar.
> 
> We are in complete control of the name.
> If you want we can call it "_m3_padding_for_alignment"
> or "-m3_nothing_to_see_here"
> or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)

I doubt it, but they might need to be valid linker identifiers.  If there is a
character that is not legal in Modula-3 identifiers but legal here, it would be nice
to use it in generated things like this.  Then a debugger could normally suppress
displaying it, yet not be fooled by a Modula-3 programmer's actually declaring, e.g.,
_m3gap_8_56 in source code.  There are other places this comes up.

> 
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> From: dragisha at m3w.org
>> To: m3devel at elegosoft.com
>> Date: Tue, 5 Oct 2010 15:32:30 +0200
>> Subject: [M3devel] m3gap.... what is it and what does this mean?
>>
>> (gdb) p event
>> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 =
>> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {},
>> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>>
>>
>> VAR
>> event: Gdk.EventKey;
>>
>> EventKey = RECORD
>> type: EventType;
>> window: WindowStar;
>> send_event: char;
>> time: unsigned_long_int;
>> state: unsigned_int;
>> keyval: unsigned_int;
>> length: int;
>> string: char_star;
>> hardware_keycode: unsigned_short_int;
>> group: unsigned_char;
>> END;
>>
>> also with m3gdb....
>>
>> (m3gdb) p event
>> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
>> send_event = 0 '\000',
>> _m3gap_136_56 = {}, time = 49, state = -937844736,
>> keyval = 32616, length = 23801648,
>> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
>> \000", hardware_keycode = 0, group = 0 '\000',
>> _m3gap_472_40 = {}}
>>
>> --
>> Dragi?a Duri? 
>>
>  		 	   		  


From rodney_bates at lcwb.coop  Tue Oct  5 21:29:22 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 05 Oct 2010 14:29:22 -0500
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286285550.3514.20.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>
Message-ID: <4CAB7C92.7040305@lcwb.coop>

Are the gdb and m3gdb prints for the same value of 'event'?   Several of the fields show different
values.

Dragi?a Duri? wrote:
> (gdb) p event
> $1 = {type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 = 
>     {<No data fields>}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {<No data fields>}, 
>   string = 0xa <Address 0xa out of bounds>, hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {<No data fields>}}
> 
> 
>  VAR
>    event: Gdk.EventKey;
> 
>   EventKey = RECORD 
>     type: EventType;
>     window: WindowStar;
>     send_event: char;
>     time: unsigned_long_int;  
>     state: unsigned_int;
>     keyval: unsigned_int;
>     length: int;
>     string: char_star;
>     hardware_keycode: unsigned_short_int;
>     group: unsigned_char;
>   END;
> 
> also with m3gdb....
> 
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x0,
> send_event = 0 '\000', 
>   _m3gap_136_56 = {<No data fields>}, time = 49, state = -937844736,
> keyval = 32616, length = 23801648, 
>   _m3gap_352_32 = {<No data fields>}, string = 0x7f68c839be10 "\001
> \000", hardware_keycode = 0, group = 0 '\000', 
>   _m3gap_472_40 = {<No data fields>}}
> 


From hosking at cs.purdue.edu  Tue Oct  5 22:04:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 5 Oct 2010 16:04:06 -0400
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <4CAB7BF1.3050801@lcwb.coop>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	<COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>
	<4CAB7BF1.3050801@lcwb.coop>
Message-ID: <291C297F-27A1-4F27-9D67-2F0C11ED1F3A@cs.purdue.edu>

M3 ids cannot begin with "_".

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 5 Oct 2010, at 15:26, Rodney M. Bates wrote:

> 
> 
> Jay K wrote:
>> Hey, look, until August, stock gdb never showed any fields!
>> The front does layout, it might tell the backend:
>> struct {
>>  integer a at offset 4, size 4
>>  integer b at offset 12, size 4
>> }
>> in which case the backend will generate a "gap" field at offset 8, size 4
>> I suspect we might not have to generate the fields.
>> I'm nervous that the backend might do its own layout and move up b to offset 8 otherwise.
>> And there was other code in the backing doing similar.
>> We are in complete control of the name.
>> If you want we can call it "_m3_padding_for_alignment"
>> or "-m3_nothing_to_see_here"
>> or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)
> 
> I doubt it, but they might need to be valid linker identifiers.  If there is a
> character that is not legal in Modula-3 identifiers but legal here, it would be nice
> to use it in generated things like this.  Then a debugger could normally suppress
> displaying it, yet not be fooled by a Modula-3 programmer's actually declaring, e.g.,
> _m3gap_8_56 in source code.  There are other places this comes up.
> 
>> - Jay
>> ----------------------------------------
>>> From: dragisha at m3w.org
>>> To: m3devel at elegosoft.com
>>> Date: Tue, 5 Oct 2010 15:32:30 +0200
>>> Subject: [M3devel] m3gap.... what is it and what does this mean?
>>> 
>>> (gdb) p event
>>> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 =
>>> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {},
>>> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>>> 
>>> 
>>> VAR
>>> event: Gdk.EventKey;
>>> 
>>> EventKey = RECORD
>>> type: EventType;
>>> window: WindowStar;
>>> send_event: char;
>>> time: unsigned_long_int;
>>> state: unsigned_int;
>>> keyval: unsigned_int;
>>> length: int;
>>> string: char_star;
>>> hardware_keycode: unsigned_short_int;
>>> group: unsigned_char;
>>> END;
>>> 
>>> also with m3gdb....
>>> 
>>> (m3gdb) p event
>>> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
>>> send_event = 0 '\000',
>>> _m3gap_136_56 = {}, time = 49, state = -937844736,
>>> keyval = 32616, length = 23801648,
>>> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
>>> \000", hardware_keycode = 0, group = 0 '\000',
>>> _m3gap_472_40 = {}}
>>> 
>>> --
>>> Dragi?a Duri? 
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101005/18a08712/attachment.html>

From dragisha at m3w.org  Tue Oct  5 22:58:54 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 05 Oct 2010 22:58:54 +0200
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <4CAB7C92.7040305@lcwb.coop>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	<4CAB7C92.7040305@lcwb.coop>
Message-ID: <1286312334.3514.35.camel@boromir.m3w.org>

It was same debugging path, but event is X event, so...

On Tue, 2010-10-05 at 14:29 -0500, Rodney M. Bates wrote:
> Are the gdb and m3gdb prints for the same value of 'event'?   Several
> of the fields show different
> values.
> 
> Dragi?a Duri? wrote:
> > (gdb) p event 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Wed Oct  6 00:53:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 22:53:56 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286312334.3514.35.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, <4CAB7C92.7040305@lcwb.coop>,
	<1286312334.3514.35.camel@boromir.m3w.org>
Message-ID: <COL101-W17C90050417FE64E79E72E66D0@phx.gbl>


1) Let's not be too quick to assume the new debugging stuff is correct.
? I just started it in August, in response to internal compiler errors passing records by value on SPARC64.
? (seems unrelated, but it isn't; there isn't really "debug" stuff in gcc backends, there are merely
? types in the trees, and we were creating records with size but not fields at all, pretty poor
? gcc citizens imho...)
? Though they probably often are correct. I know the level of indirection is sometimes wrong though, like
? on record parameters.

2) The numbers are bit offset and bit size, so not as big as you might think.
I can make them trivially byte offsets, if they are multiples of 8, at the cost
of possible confusion when they aren't.
Or they can just be called _m3gap1, _m3gap2, numbered either per-unit
or per-type.

I could also try not putting them in at all, but merely bumping the offset
of the next field in the same way as current and hoping backend
doesn't relayout and move them toward the start.

?- Jay



----------------------------------------
> From: dragisha at m3w.org
> To: rodney_bates at lcwb.coop
> Date: Tue, 5 Oct 2010 22:58:54 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... what is it and what does this mean?
>
> It was same debugging path, but event is X event, so...
>
> On Tue, 2010-10-05 at 14:29 -0500, Rodney M. Bates wrote:
> > Are the gdb and m3gdb prints for the same value of 'event'? Several
> > of the fields show different
> > values.
> >
> > Dragi?a Duri? wrote:
> > > (gdb) p event
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Wed Oct  6 00:49:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 22:49:57 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <291C297F-27A1-4F27-9D67-2F0C11ED1F3A@cs.purdue.edu>
References: <1286285550.3514.20.camel@boromir.m3w.org>,
	<COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>,
	<4CAB7BF1.3050801@lcwb.coop>,
	<291C297F-27A1-4F27-9D67-2F0C11ED1F3A@cs.purdue.edu>
Message-ID: <COL101-W55C57390007CB07BEF6C3DE66D0@phx.gbl>


The names are generated in the backend.
Use of leading underscore is therefore good -- it can't clash with "real" data.

?- Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 5 Oct 2010 16:04:06 -0400
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... what is it and what does this mean?
>
> M3 ids cannot begin with "_".
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 5 Oct 2010, at 15:26, Rodney M. Bates wrote:
>
>
>
> Jay K wrote:
> Hey, look, until August, stock gdb never showed any fields!
> The front does layout, it might tell the backend:
> struct {
> integer a at offset 4, size 4
> integer b at offset 12, size 4
> }
> in which case the backend will generate a "gap" field at offset 8, size 4
> I suspect we might not have to generate the fields.
> I'm nervous that the backend might do its own layout and move up b to
> offset 8 otherwise.
> And there was other code in the backing doing similar.
> We are in complete control of the name.
> If you want we can call it "_m3_padding_for_alignment"
> or "-m3_nothing_to_see_here"
> or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)
>
> I doubt it, but they might need to be valid linker identifiers. If
> there is a
> character that is not legal in Modula-3 identifiers but legal here, it
> would be nice
> to use it in generated things like this. Then a debugger could
> normally suppress
> displaying it, yet not be fooled by a Modula-3 programmer's actually
> declaring, e.g.,
> _m3gap_8_56 in source code. There are other places this comes up.
>
> - Jay
> ----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Tue, 5 Oct 2010 15:32:30 +0200
> Subject: [M3devel] m3gap.... what is it and what does this mean?
>
> (gdb) p event
> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event =
> 0 '\000', _m3gap_136_56 =
> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024,
> _m3gap_352_32 = {},
> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>
>
> VAR
> event: Gdk.EventKey;
>
> EventKey = RECORD
> type: EventType;
> window: WindowStar;
> send_event: char;
> time: unsigned_long_int;
> state: unsigned_int;
> keyval: unsigned_int;
> length: int;
> string: char_star;
> hardware_keycode: unsigned_short_int;
> group: unsigned_char;
> END;
>
> also with m3gdb....
>
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> send_event = 0 '\000',
> _m3gap_136_56 = {}, time = 49, state = -937844736,
> keyval = 32616, length = 23801648,
> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
> \000", hardware_keycode = 0, group = 0 '\000',
> _m3gap_472_40 = {}}
>
> --
> Dragi?a Duri?
>
>
 		 	   		  

From dragisha at m3w.org  Wed Oct  6 01:48:56 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 06 Oct 2010 01:48:56 +0200
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <COL101-W17C90050417FE64E79E72E66D0@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	, <4CAB7C92.7040305@lcwb.coop>,
	<1286312334.3514.35.camel@boromir.m3w.org>
	<COL101-W17C90050417FE64E79E72E66D0@phx.gbl>
Message-ID: <1286322536.3514.41.camel@boromir.m3w.org>

They are nice as they are, as long as debugging works. Information on
alignment is good to have.

On Tue, 2010-10-05 at 22:53 +0000, Jay K wrote:
> 2) The numbers are bit offset and bit size, so not as big as you might
> think.
> I can make them trivially byte offsets, if they are multiples of 8, at
> the cost
> of possible confusion when they aren't.
> Or they can just be called _m3gap1, _m3gap2, numbered either per-unit
> or per-type.
> 
> I could also try not putting them in at all, but merely bumping the
> offset
> of the next field in the same way as current and hoping backend
> doesn't relayout and move them toward the start. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Wed Oct  6 03:10:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 01:10:30 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286322536.3514.41.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>,,
	<4CAB7C92.7040305@lcwb.coop>, ,
	<1286312334.3514.35.camel@boromir.m3w.org>,
	<COL101-W17C90050417FE64E79E72E66D0@phx.gbl>,
	<1286322536.3514.41.camel@boromir.m3w.org>
Message-ID: <COL101-W27409A49660B73E76EDE1DE66E0@phx.gbl>


Implied tedious request:
  write some code
  including printing out the values with IO. or RTIO.
  step through
  view in debugger
  verify it all matches
  think about how enums should appear, they are perhaps too short now
  Try subranges, enums, objects, records, fixed arrays, open arrays.
    I'm positive not all of that works though, e.g. arrays for certain. 
 
 - Jay



----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Wed, 6 Oct 2010 01:48:56 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... what is it and what does this mean?
>
> They are nice as they are, as long as debugging works. Information on
> alignment is good to have.
>
> On Tue, 2010-10-05 at 22:53 +0000, Jay K wrote:
> > 2) The numbers are bit offset and bit size, so not as big as you might
> > think.
> > I can make them trivially byte offsets, if they are multiples of 8, at
> > the cost
> > of possible confusion when they aren't.
> > Or they can just be called _m3gap1, _m3gap2, numbered either per-unit
> > or per-type.
> >
> > I could also try not putting them in at all, but merely bumping the
> > offset
> > of the next field in the same way as current and hoping backend
> > doesn't relayout and move them toward the start.
> --
> Dragi?a Duri? 
> 		 	   		  

From jay.krell at cornell.edu  Wed Oct  6 11:20:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 09:20:14 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
Message-ID: <COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>


I see. It occurs even on a cross build.
It should be better now -- by avoiding certain large changes on this platform.
A C generating backend is getting ever more tempting..

?- Jay

----------------------------------------
> Date: Tue, 5 Oct 2010 12:35:45 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] compilation failure on Solaris
>
> There are segmentation faults during compilation of Lex.m3, see:
>
> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>
> === package m3-libs/libm3 ===
> +++ cm3 -build
> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> +++
> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> m3_backend => 4
> m3cc (aka cm3cg) failed compiling: Lex.mc
> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> m3_backend => 4
> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From hosking at cs.purdue.edu  Wed Oct  6 15:07:31 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 09:07:31 -0400
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>
Message-ID: <766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>

Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"?  I am wary of special-casing builds of a system as complex as gcc depending on target.

On 6 Oct 2010, at 05:20, Jay K wrote:

> 
> I see. It occurs even on a cross build.
> It should be better now -- by avoiding certain large changes on this platform.
> A C generating backend is getting ever more tempting..
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Tue, 5 Oct 2010 12:35:45 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] compilation failure on Solaris
>> 
>> There are segmentation faults during compilation of Lex.m3, see:
>> 
>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>> 
>> === package m3-libs/libm3 ===
>> +++ cm3 -build
>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
>> +++
>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> m3_backend => 4
>> m3cc (aka cm3cg) failed compiling: Lex.mc
>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> m3_backend => 4
>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>> 
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> 
> 		 	   		  



From jay.krell at cornell.edu  Wed Oct  6 15:24:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 13:24:30 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>
Message-ID: <COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>


It isn't easy. I'm lazy.
I flip one thing and voila cm3 crashes.
I compare e.g. m3core before/after, but there are many changes.

There have been significant changes since August -- starting to provide half decent type information in the trees.
The ramifications of this are potentially very large, and they seem to vary per-target.

Used to be records never had any fields, just a size. That was probably good at tying the compiler's hands,
but it was bad for debugging with regular gdb.

Plus the long time we used volatile.
Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
until relatively recently (nested functions that gcc thinks are unused, but are referenced
from the module data).

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 09:07:31 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] compilation failure on Solaris
>
> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
>
> On 6 Oct 2010, at 05:20, Jay K wrote:
>
> >
> > I see. It occurs even on a cross build.
> > It should be better now -- by avoiding certain large changes on this platform.
> > A C generating backend is getting ever more tempting..
> >
> > - Jay
> >
> > ----------------------------------------
> >> Date: Tue, 5 Oct 2010 12:35:45 +0200
> >> From: wagner at elegosoft.com
> >> To: m3devel at elegosoft.com
> >> Subject: [M3devel] compilation failure on Solaris
> >>
> >> There are segmentation faults during compilation of Lex.m3, see:
> >>
> >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
> >>
> >> === package m3-libs/libm3 ===
> >> +++ cm3 -build
> >> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> >> +++
> >> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See for instructions.
> >> m3_backend => 4
> >> m3cc (aka cm3cg) failed compiling: Lex.mc
> >> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See for instructions.
> >> m3_backend => 4
> >> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
> >>
> >> Olaf
> >> --
> >> Olaf Wagner -- elego Software Solutions GmbH
> >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>
> >
>
 		 	   		  

From jay.krell at cornell.edu  Wed Oct  6 15:30:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 13:30:00 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
Message-ID: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>


some random notes

Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
? Easy test is to run cm3 without a neighboring cm3.cfg and the error
? is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg

Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
? Same easy test, but it crashes upon first attempt to raise an exception.

Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
? NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
? 
Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
? Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.

Meanwhile I think many other targets are working ok with 4.5.
Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Wed Oct  6 16:34:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 10:34:45 -0400
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>
Message-ID: <43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>

I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated. 

Sent from my iPhone

On Oct 6, 2010, at 9:24 AM, Jay K <jay.krell at cornell.edu> wrote:

> Plus the long time we used volatile.
> Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
> until relatively recently (nested functions that gcc thinks are unused, but are referenced
> from the module data).
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 6 Oct 2010 09:07:31 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] compilation failure on Solaris
>> 
>> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
>> 
>> On 6 Oct 2010, at 05:20, Jay K wrote:
>> 
>>> 
>>> I see. It occurs even on a cross build.
>>> It should be better now -- by avoiding certain large changes on this platform.
>>> A C generating backend is getting ever more tempting..
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
>>>> From: wagner at elegosoft.com
>>>> To: m3devel at elegosoft.com
>>>> Subject: [M3devel] compilation failure on Solaris
>>>> 
>>>> There are segmentation faults during compilation of Lex.m3, see:
>>>> 
>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>>>> 
>>>> === package m3-libs/libm3 ===
>>>> +++ cm3 -build
>>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
>>>> +++
>>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
>>>> Please submit a full bug report,
>>>> with preprocessed source if appropriate.
>>>> See for instructions.
>>>> m3_backend => 4
>>>> m3cc (aka cm3cg) failed compiling: Lex.mc
>>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
>>>> Please submit a full bug report,
>>>> with preprocessed source if appropriate.
>>>> See for instructions.
>>>> m3_backend => 4
>>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>>>> 
>>>> Olaf
>>>> --
>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>>> 
>>> 
>> 
>                         


From hosking at cs.purdue.edu  Wed Oct  6 16:48:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 10:48:21 -0400
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
Message-ID: <3A129857-64E9-49C3-BEA3-71BFFCE4E282@cs.purdue.edu>



On 6 Oct 2010, at 09:30, Jay K wrote:

> 
> some random notes
> 
> Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
>   Easy test is to run cm3 without a neighboring cm3.cfg and the error
>   is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg

Used not to break.  I did test this at one point.

> Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
>   Same easy test, but it crashes upon first attempt to raise an exception.
> 
> Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
>   NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
>   
> Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
>   Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> 
> Meanwhile I think many other targets are working ok with 4.5.
> Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Wed Oct  6 17:03:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 15:03:02 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>,
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>,
	<43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
Message-ID: <COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>


There is only one instance in the tree currently that I know of, and I write it relatively recently.
? (And I can workaround it easily by unnesting the function.)
Perhaps it was never seen before?

Here it is:


jbook2:src jay$ edit lego/ZChassisVBT.m3
jbook2:src jay$ pwd
/dev2/cm3/m3-ui/vbtkit/src


PROCEDURE NewBtn (uglyPosixText, win32ppm: TEXT; shadow: Shadow.T): VBT.T =

PROCEDURE Posix (t: TEXT; shadow: Shadow.T): VBT.T =
? BEGIN
??? WITH textVBT = TextVBT.New (t) DO
????? TextVBT.SetFont (textVBT, Font.BuiltIn, shadow);
????? RETURN NEW (ShadowedFeedbackVBT.T).init (textVBT, shadow)
??? END
? END Posix;

PROCEDURE Win32 (name: TEXT; shadow: Shadow.T): VBT.T =
? VAR
??? pm := VBTKitResources.GetPixmap (name);
??? pixvbt := NEW(PixmapVBT.T).init(pm, halign := 0.0, valign := 0.0,
??????????????????????????????? op := PaintOp.Copy);
? BEGIN
??? RETURN NEW (ShadowedFeedbackVBT.T).init (pixvbt, shadow)
? END Win32;

? BEGIN
??? CASE Compiler.ThisOS OF
????? | Compiler.OS.POSIX => RETURN Posix(uglyPosixText, shadow);
????? | Compiler.OS.WIN32 => RETURN Win32(win32ppm, shadow);
??? END;
? END NewBtn;

Of course, between Posix and Win32, one is dead.

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 10:34:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] compilation failure on Solaris
>
> I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated.
>
> Sent from my iPhone
>
> On Oct 6, 2010, at 9:24 AM, Jay K  wrote:
>
> > Plus the long time we used volatile.
> > Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
> > until relatively recently (nested functions that gcc thinks are unused, but are referenced
> > from the module data).
> >
> > - Jay
> >
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Wed, 6 Oct 2010 09:07:31 -0400
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] compilation failure on Solaris
> >>
> >> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
> >>
> >> On 6 Oct 2010, at 05:20, Jay K wrote:
> >>
> >>>
> >>> I see. It occurs even on a cross build.
> >>> It should be better now -- by avoiding certain large changes on this platform.
> >>> A C generating backend is getting ever more tempting..
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
> >>>> From: wagner at elegosoft.com
> >>>> To: m3devel at elegosoft.com
> >>>> Subject: [M3devel] compilation failure on Solaris
> >>>>
> >>>> There are segmentation faults during compilation of Lex.m3, see:
> >>>>
> >>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> >>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
> >>>>
> >>>> === package m3-libs/libm3 ===
> >>>> +++ cm3 -build
> >>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> >>>> +++
> >>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> >>>> Please submit a full bug report,
> >>>> with preprocessed source if appropriate.
> >>>> See for instructions.
> >>>> m3_backend => 4
> >>>> m3cc (aka cm3cg) failed compiling: Lex.mc
> >>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> >>>> Please submit a full bug report,
> >>>> with preprocessed source if appropriate.
> >>>> See for instructions.
> >>>> m3_backend => 4
> >>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
> >>>>
> >>>> Olaf
> >>>> --
> >>>> Olaf Wagner -- elego Software Solutions GmbH
> >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>>>
> >>>
> >>
> >
 		 	   		  

From dragisha at m3w.org  Wed Oct  6 18:49:54 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 06 Oct 2010 18:49:54 +0200
Subject: [M3devel] GCC version, danger zone
In-Reply-To: <COL101-W6126EB7972E7D5607EA24FE66E0@phx.gbl>
References: <20101006104543.A18DB2474003@birch.elegosoft.com>
	, , <D487B610-E139-4791-83C6-9B9824A34DD9@cs.purdue.edu>
	, <COL101-W63B0B6343EF7EBA88858AFE66E0@phx.gbl>
	, <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu>
	<COL101-W6126EB7972E7D5607EA24FE66E0@phx.gbl>
Message-ID: <1286383794.3849.5.camel@boromir.m3w.org>

GNU Pascal team capitulated on GCC backend, due to galloping changes GCC
team is making.
SRC people fixed SRCM3 on particular GCC release just because their
change rate is rampant.
Let's be careful to not go way of GNU Pascal -> way of dodo. Please!

On Wed, 2010-10-06 at 15:06 +0000, Jay K wrote:
> 
> Let me maybe get 4.5.1 working before -O3.
> Granted..I agree it was probably working as recently as the recent
> release.
> What changed since then? In the 4.3 tree? ==> I moved from 4.3.0 to
> 4.3.5.
> So if we want to find -O3 working, it is probably there.
> 
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Wed Oct  6 19:50:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 13:50:00 -0400
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>,
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>,
	<43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
	<COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>
Message-ID: <C1A1128F-9125-4499-896C-F63D22455DBC@cs.purdue.edu>

This code has been around a long time.


On 6 Oct 2010, at 11:03, Jay K wrote:

> 
> There is only one instance in the tree currently that I know of, and I write it relatively recently.
>   (And I can workaround it easily by unnesting the function.)
> Perhaps it was never seen before?
> 
> Here it is:
> 
> 
> jbook2:src jay$ edit lego/ZChassisVBT.m3
> jbook2:src jay$ pwd
> /dev2/cm3/m3-ui/vbtkit/src
> 
> 
> PROCEDURE NewBtn (uglyPosixText, win32ppm: TEXT; shadow: Shadow.T): VBT.T =
> 
> PROCEDURE Posix (t: TEXT; shadow: Shadow.T): VBT.T =
>   BEGIN
>     WITH textVBT = TextVBT.New (t) DO
>       TextVBT.SetFont (textVBT, Font.BuiltIn, shadow);
>       RETURN NEW (ShadowedFeedbackVBT.T).init (textVBT, shadow)
>     END
>   END Posix;
> 
> PROCEDURE Win32 (name: TEXT; shadow: Shadow.T): VBT.T =
>   VAR
>     pm := VBTKitResources.GetPixmap (name);
>     pixvbt := NEW(PixmapVBT.T).init(pm, halign := 0.0, valign := 0.0,
>                                 op := PaintOp.Copy);
>   BEGIN
>     RETURN NEW (ShadowedFeedbackVBT.T).init (pixvbt, shadow)
>   END Win32;
> 
>   BEGIN
>     CASE Compiler.ThisOS OF
>       | Compiler.OS.POSIX => RETURN Posix(uglyPosixText, shadow);
>       | Compiler.OS.WIN32 => RETURN Win32(win32ppm, shadow);
>     END;
>   END NewBtn;
> 
> Of course, between Posix and Win32, one is dead.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 6 Oct 2010 10:34:45 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] compilation failure on Solaris
>> 
>> I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated.
>> 
>> Sent from my iPhone
>> 
>> On Oct 6, 2010, at 9:24 AM, Jay K  wrote:
>> 
>>> Plus the long time we used volatile.
>>> Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
>>> until relatively recently (nested functions that gcc thinks are unused, but are referenced
>>> from the module data).
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 6 Oct 2010 09:07:31 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] compilation failure on Solaris
>>>> 
>>>> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
>>>> 
>>>> On 6 Oct 2010, at 05:20, Jay K wrote:
>>>> 
>>>>> 
>>>>> I see. It occurs even on a cross build.
>>>>> It should be better now -- by avoiding certain large changes on this platform.
>>>>> A C generating backend is getting ever more tempting..
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
>>>>>> From: wagner at elegosoft.com
>>>>>> To: m3devel at elegosoft.com
>>>>>> Subject: [M3devel] compilation failure on Solaris
>>>>>> 
>>>>>> There are segmentation faults during compilation of Lex.m3, see:
>>>>>> 
>>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
>>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>>>>>> 
>>>>>> === package m3-libs/libm3 ===
>>>>>> +++ cm3 -build
>>>>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
>>>>>> +++
>>>>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
>>>>>> Please submit a full bug report,
>>>>>> with preprocessed source if appropriate.
>>>>>> See for instructions.
>>>>>> m3_backend => 4
>>>>>> m3cc (aka cm3cg) failed compiling: Lex.mc
>>>>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
>>>>>> Please submit a full bug report,
>>>>>> with preprocessed source if appropriate.
>>>>>> See for instructions.
>>>>>> m3_backend => 4
>>>>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>>>>>> 
>>>>>> Olaf
>>>>>> --
>>>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>>>>> 
>>>>> 
>>>> 
>>> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed Oct  6 19:53:48 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 13:53:48 -0400
Subject: [M3devel] GCC version, danger zone
In-Reply-To: <1286383794.3849.5.camel@boromir.m3w.org>
References: <20101006104543.A18DB2474003@birch.elegosoft.com> , ,
	<D487B610-E139-4791-83C6-9B9824A34DD9@cs.purdue.edu> ,
	<COL101-W63B0B6343EF7EBA88858AFE66E0@phx.gbl> ,
	<074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu>
	<COL101-W6126EB7972E7D5607EA24FE66E0@phx.gbl>
	<1286383794.3849.5.camel@boromir.m3w.org>
Message-ID: <5D4465D1-C461-4739-A288-6EA6E94F966C@cs.purdue.edu>

Good point!

On 6 Oct 2010, at 12:49, Dragi?a Duri? wrote:

> GNU Pascal team capitulated on GCC backend, due to galloping changes GCC
> team is making.
> SRC people fixed SRCM3 on particular GCC release just because their
> change rate is rampant.
> Let's be careful to not go way of GNU Pascal -> way of dodo. Please!
> 
> On Wed, 2010-10-06 at 15:06 +0000, Jay K wrote:
>> 
>> Let me maybe get 4.5.1 working before -O3.
>> Granted..I agree it was probably working as recently as the recent
>> release.
>> What changed since then? In the 4.3 tree? ==> I moved from 4.3.0 to
>> 4.3.5.
>> So if we want to find -O3 working, it is probably there.
>> 
>> 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>



From dragisha at m3w.org  Wed Oct  6 22:40:12 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 06 Oct 2010 22:40:12 +0200
Subject: [M3devel] static linking of some C libs...
Message-ID: <1286397612.7401.0.camel@boromir.m3w.org>

I would like to statically link only some C libs. How to do it?
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu Oct  7 00:37:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 22:37:35 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <C1A1128F-9125-4499-896C-F63D22455DBC@cs.purdue.edu>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>,
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>,
	<43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
	<COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>,
	<C1A1128F-9125-4499-896C-F63D22455DBC@cs.purdue.edu>
Message-ID: <COL101-W266E6E413DA34C43D955B2E66E0@phx.gbl>


The construct that leads the backend when compiling "unit at a time" to throw out referenced nested function dates to only May 2010.

http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/ZChassisVBT.m3

?- Jay


----------------------------------------
> Subject: Re: [M3devel] compilation failure on Solaris
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 13:50:00 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> This code has been around a long time.
>
>
> On 6 Oct 2010, at 11:03, Jay K wrote:
>
> >
> > There is only one instance in the tree currently that I know of, and I write it relatively recently.
> > (And I can workaround it easily by unnesting the function.)
> > Perhaps it was never seen before?
> >
> > Here it is:
> >
> >
> > jbook2:src jay$ edit lego/ZChassisVBT.m3
> > jbook2:src jay$ pwd
> > /dev2/cm3/m3-ui/vbtkit/src
> >
> >
> > PROCEDURE NewBtn (uglyPosixText, win32ppm: TEXT; shadow: Shadow.T): VBT.T =
> >
> > PROCEDURE Posix (t: TEXT; shadow: Shadow.T): VBT.T =
> > BEGIN
> > WITH textVBT = TextVBT.New (t) DO
> > TextVBT.SetFont (textVBT, Font.BuiltIn, shadow);
> > RETURN NEW (ShadowedFeedbackVBT.T).init (textVBT, shadow)
> > END
> > END Posix;
> >
> > PROCEDURE Win32 (name: TEXT; shadow: Shadow.T): VBT.T =
> > VAR
> > pm := VBTKitResources.GetPixmap (name);
> > pixvbt := NEW(PixmapVBT.T).init(pm, halign := 0.0, valign := 0.0,
> > op := PaintOp.Copy);
> > BEGIN
> > RETURN NEW (ShadowedFeedbackVBT.T).init (pixvbt, shadow)
> > END Win32;
> >
> > BEGIN
> > CASE Compiler.ThisOS OF
> > | Compiler.OS.POSIX => RETURN Posix(uglyPosixText, shadow);
> > | Compiler.OS.WIN32 => RETURN Win32(win32ppm, shadow);
> > END;
> > END NewBtn;
> >
> > Of course, between Posix and Win32, one is dead.
> >
> > - Jay
> >
> >
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Wed, 6 Oct 2010 10:34:45 -0400
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] compilation failure on Solaris
> >>
> >> I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated.
> >>
> >> Sent from my iPhone
> >>
> >> On Oct 6, 2010, at 9:24 AM, Jay K wrote:
> >>
> >>> Plus the long time we used volatile.
> >>> Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
> >>> until relatively recently (nested functions that gcc thinks are unused, but are referenced
> >>> from the module data).
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> From: hosking at cs.purdue.edu
> >>>> Date: Wed, 6 Oct 2010 09:07:31 -0400
> >>>> To: jay.krell at cornell.edu
> >>>> CC: m3devel at elegosoft.com
> >>>> Subject: Re: [M3devel] compilation failure on Solaris
> >>>>
> >>>> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
> >>>>
> >>>> On 6 Oct 2010, at 05:20, Jay K wrote:
> >>>>
> >>>>>
> >>>>> I see. It occurs even on a cross build.
> >>>>> It should be better now -- by avoiding certain large changes on this platform.
> >>>>> A C generating backend is getting ever more tempting..
> >>>>>
> >>>>> - Jay
> >>>>>
> >>>>> ----------------------------------------
> >>>>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
> >>>>>> From: wagner at elegosoft.com
> >>>>>> To: m3devel at elegosoft.com
> >>>>>> Subject: [M3devel] compilation failure on Solaris
> >>>>>>
> >>>>>> There are segmentation faults during compilation of Lex.m3, see:
> >>>>>>
> >>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> >>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
> >>>>>>
> >>>>>> === package m3-libs/libm3 ===
> >>>>>> +++ cm3 -build
> >>>>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> >>>>>> +++
> >>>>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> >>>>>> Please submit a full bug report,
> >>>>>> with preprocessed source if appropriate.
> >>>>>> See for instructions.
> >>>>>> m3_backend => 4
> >>>>>> m3cc (aka cm3cg) failed compiling: Lex.mc
> >>>>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> >>>>>> Please submit a full bug report,
> >>>>>> with preprocessed source if appropriate.
> >>>>>> See for instructions.
> >>>>>> m3_backend => 4
> >>>>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
> >>>>>>
> >>>>>> Olaf
> >>>>>> --
> >>>>>> Olaf Wagner -- elego Software Solutions GmbH
> >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 00:52:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 22:52:22 +0000
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <1286397612.7401.0.camel@boromir.m3w.org>
References: <1286397612.7401.0.camel@boromir.m3w.org>
Message-ID: <COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>


I don't have a good answer here.
I have some bad ones: Only have static libraries.
We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.


Microsoft link doesn't really have the notion you ask for. It just has libraries.
It has a better model imho.
It never links to .so/.dll files.
It links to .libs.
Those .libs might be "normal" static ones with real code in them,
or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
(In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
.libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
once you know to look.)


The Unix linkers have a wierd model where they probe around like mad and are willing
to "link" to an .so/.dll file with no .lib/.a in sight.
It is good in terms of "self description" but bad in terms of conflating runtime and tools.


In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
is the norm.


The import libraries are to a large extent a small transform of the .dll files, so, well,
there is something to the Unix model. It isn't completely crazy, it seems better at first
maybe but it is wierd and inferior ultimately.


So, for Windows, which I suspect you are talking about, point the linker at a static library.
The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
environment variable, or the -libpath command line option. But it doesn't make its own
static vs. dynamic decisions or probe around in a way to do so, except to the extent
that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
full paths to .lib files, what you ask for is what you get.


(I do suspect you are asking specifically about Windows.)


Modula-3 does something slightly tricky in order to allow static and dynamic and
for it to later chose. It makes static libraries for everything: foo.lib.sa.
"sa" = standalone.
And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
If it is build_standalone, it renames foo.lib.sa to foo.lib.


Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.


All this is done by cm3/the config file though. No trickery or probing in the linker.


It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
And how there is m3core.dll, but no m3quake.dll.


I does basically identical for Unix even.
Part of the Unix story is using -fPIC always.
It is an inefficiency sometimes, but imho worth it.
I wish Windows code was always position independent, rather than worry
about base addresses and relocation costs (prior to Vista, relocs were
applied to entire .dll at load, killing demand paging and page sharing;
as of Vista, they are applied at page-in, which preserves demand paging
but still loses on page sharing).


?-Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Wed, 6 Oct 2010 22:40:12 +0200
> Subject: [M3devel] static linking of some C libs...
>
> I would like to statically link only some C libs. How to do it?
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 01:20:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 23:20:12 +0000
Subject: [M3devel] gcc 4.5 + AMD64_SOLARIS fyi
Message-ID: <COL101-W18C65A5BA10B392652EBDFE66E0@phx.gbl>


m3cc (aka cm3cg) failed compiling: Unicode.mc
new source -> compiling Address.i3
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated


occurs in pretty much every file

?- Jay
 		 	   		  

From dragisha at m3w.org  Thu Oct  7 07:58:55 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 07 Oct 2010 07:58:55 +0200
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>
References: <1286397612.7401.0.camel@boromir.m3w.org>
	<COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>
Message-ID: <1286431135.7401.13.camel@boromir.m3w.org>

gcc GSTABS_TO_WARN_COMMON_LD_ARGS -Wl,-rpath,/usr/local/cm3/bin/../lib  -o MYPGM  _m3main.o MYOBJS /usr/local/cm3/pkg/openssl/AMD64_LINUX/libhm3openssl.a /usr/lib64/libssl.a /usr/lib64/libcrypto.a -lz -L/usr/local/cm3/pkg/libm3/AMD64_LINUX -lm3 -L/usr/local/cm3/pkg/m3core/AMD64_LINUX -lm3core -lm -ldl -lkrb5 -pthread

This is what I made.... Manually of course.
      * build_standalone() in m3makefile ;
      * cm3 -commands (this fails at linking because it cannot succeed
        if fully static, but I get original linking command I edit
        later)
      * cd ../AMD64_LINUX
      * command from first line...

build_standalone() is just setting build_shared somewhere in Builder.m3
to FALSE.. So it's all or nothing. What we need is a way to specify
(best would be in main app m3makefile, so installed libraries can be
static on demand) what libraries we need static. With that info passed
through m3makefile, current quake code can produce custom command.

If nobody has time/will to do this, I'll do it after I deliver my
current project.

On Wed, 2010-10-06 at 22:52 +0000, Jay K wrote:
> I don't have a good answer here.
> I have some bad ones: Only have static libraries.
> We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.
> 
> 
> Microsoft link doesn't really have the notion you ask for. It just has libraries.
> It has a better model imho.
> It never links to .so/.dll files.
> It links to .libs.
> Those .libs might be "normal" static ones with real code in them,
> or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
> (In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
> .libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
> It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
> However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
> once you know to look.)
> 
> 
> The Unix linkers have a wierd model where they probe around like mad and are willing
> to "link" to an .so/.dll file with no .lib/.a in sight.
> It is good in terms of "self description" but bad in terms of conflating runtime and tools.
> 
> 
> In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
> is the norm.
> 
> 
> The import libraries are to a large extent a small transform of the .dll files, so, well,
> there is something to the Unix model. It isn't completely crazy, it seems better at first
> maybe but it is wierd and inferior ultimately.
> 
> 
> So, for Windows, which I suspect you are talking about, point the linker at a static library.
> The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
> environment variable, or the -libpath command line option. But it doesn't make its own
> static vs. dynamic decisions or probe around in a way to do so, except to the extent
> that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
> full paths to .lib files, what you ask for is what you get.
> 
> 
> (I do suspect you are asking specifically about Windows.)
> 
> 
> Modula-3 does something slightly tricky in order to allow static and dynamic and
> for it to later chose. It makes static libraries for everything: foo.lib.sa.
> "sa" = standalone.
> And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
> If it is build_standalone, it renames foo.lib.sa to foo.lib.
> 
> 
> Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
> If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.
> 
> 
> All this is done by cm3/the config file though. No trickery or probing in the linker.
> 
> 
> It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
> And how there is m3core.dll, but no m3quake.dll.
> 
> 
> I does basically identical for Unix even.
> Part of the Unix story is using -fPIC always.
> It is an inefficiency sometimes, but imho worth it.
> I wish Windows code was always position independent, rather than worry
> about base addresses and relocation costs (prior to Vista, relocs were
> applied to entire .dll at load, killing demand paging and page sharing;
> as of Vista, they are applied at page-in, which preserves demand paging
> but still loses on page sharing).
> 
> 
>  -Jay
> 
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: m3devel at elegosoft.com
> > Date: Wed, 6 Oct 2010 22:40:12 +0200
> > Subject: [M3devel] static linking of some C libs...
> >
> > I would like to statically link only some C libs. How to do it?
> > --
> > Dragi?a Duri? 
> >
>  		 	   		  

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu Oct  7 08:13:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 06:13:54 +0000
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <1286431135.7401.13.camel@boromir.m3w.org>
References: <1286397612.7401.0.camel@boromir.m3w.org>,
	<COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>,
	<1286431135.7401.13.camel@boromir.m3w.org>
Message-ID: <COL101-W5E9607FC46DFC67A99F8EE66F0@phx.gbl>


Right.
What you want something like:
import_standalone("libfoo")
or import_static("libfoo")

shouldn't be too hard.
Just stick libfoo in some global hashtable and then when linking looks for libfoo.so vs. libfoo.a, it can use that to guide.

That is assuming libfoo is built by Modula-3 and that there are both.
If it is a C library, you'll have to do something else.

<rant>
I find Unix link command lines extremely confusing and very likely both
? having too many and too few features. What with options being in effect
until end of command line, or maybe not, or being able to turn them off/on as you go,
making it all ridiculously order-dependent. You really want to "attach" options to parameters,
or just have a dramatically simpler model and fewer options.
With Windows it is very simple. You give it a full path to a .lib or a leaf path and %LIB% is searched.
There are no options that apply to some or all .libs. It is much much much simpler, and provides
all that you need/want.
All the more reason, perhaps, to write our linker in Modula-3!
? (That'd be a great piece of a cross build story...but is a ton ton ton of work.)
Unix linkers also have a ridiculous number of confusing options like -z origin (why?), -z now (the
default on Windows, unless you use -delayload), -z combreloc, etc. etc. etc. including man pages
that list options that aren't really there because the loader doesn't support them (.e.g -z origin
historically on NetBSD).

Not to mention the historical defaults that were obviously wrong at the time and now have all been since deprecated.
? e.g. the flat namespace, leading to more confusing an inefficiency. As if emulating static linking
? was of such paramount importance that everything could be made worse in support of this misguided direction...
</rant>


?- Jay


----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 7 Oct 2010 07:58:55 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] static linking of some C libs...
>
> gcc GSTABS_TO_WARN_COMMON_LD_ARGS -Wl,-rpath,/usr/local/cm3/bin/../lib -o MYPGM _m3main.o MYOBJS /usr/local/cm3/pkg/openssl/AMD64_LINUX/libhm3openssl.a /usr/lib64/libssl.a /usr/lib64/libcrypto.a -lz -L/usr/local/cm3/pkg/libm3/AMD64_LINUX -lm3 -L/usr/local/cm3/pkg/m3core/AMD64_LINUX -lm3core -lm -ldl -lkrb5 -pthread
>
> This is what I made.... Manually of course.
> * build_standalone() in m3makefile ;
> * cm3 -commands (this fails at linking because it cannot succeed
> if fully static, but I get original linking command I edit
> later)
> * cd ../AMD64_LINUX
> * command from first line...
>
> build_standalone() is just setting build_shared somewhere in Builder.m3
> to FALSE.. So it's all or nothing. What we need is a way to specify
> (best would be in main app m3makefile, so installed libraries can be
> static on demand) what libraries we need static. With that info passed
> through m3makefile, current quake code can produce custom command.
>
> If nobody has time/will to do this, I'll do it after I deliver my
> current project.
>
> On Wed, 2010-10-06 at 22:52 +0000, Jay K wrote:
> > I don't have a good answer here.
> > I have some bad ones: Only have static libraries.
> > We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.
> >
> >
> > Microsoft link doesn't really have the notion you ask for. It just has libraries.
> > It has a better model imho.
> > It never links to .so/.dll files.
> > It links to .libs.
> > Those .libs might be "normal" static ones with real code in them,
> > or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
> > (In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
> > .libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
> > It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
> > However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
> > once you know to look.)
> >
> >
> > The Unix linkers have a wierd model where they probe around like mad and are willing
> > to "link" to an .so/.dll file with no .lib/.a in sight.
> > It is good in terms of "self description" but bad in terms of conflating runtime and tools.
> >
> >
> > In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
> > is the norm.
> >
> >
> > The import libraries are to a large extent a small transform of the .dll files, so, well,
> > there is something to the Unix model. It isn't completely crazy, it seems better at first
> > maybe but it is wierd and inferior ultimately.
> >
> >
> > So, for Windows, which I suspect you are talking about, point the linker at a static library.
> > The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
> > environment variable, or the -libpath command line option. But it doesn't make its own
> > static vs. dynamic decisions or probe around in a way to do so, except to the extent
> > that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
> > full paths to .lib files, what you ask for is what you get.
> >
> >
> > (I do suspect you are asking specifically about Windows.)
> >
> >
> > Modula-3 does something slightly tricky in order to allow static and dynamic and
> > for it to later chose. It makes static libraries for everything: foo.lib.sa.
> > "sa" = standalone.
> > And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
> > If it is build_standalone, it renames foo.lib.sa to foo.lib.
> >
> >
> > Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
> > If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.
> >
> >
> > All this is done by cm3/the config file though. No trickery or probing in the linker.
> >
> >
> > It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
> > And how there is m3core.dll, but no m3quake.dll.
> >
> >
> > I does basically identical for Unix even.
> > Part of the Unix story is using -fPIC always.
> > It is an inefficiency sometimes, but imho worth it.
> > I wish Windows code was always position independent, rather than worry
> > about base addresses and relocation costs (prior to Vista, relocs were
> > applied to entire .dll at load, killing demand paging and page sharing;
> > as of Vista, they are applied at page-in, which preserves demand paging
> > but still loses on page sharing).
> >
> >
> > -Jay
> >
> > ----------------------------------------
> > > From: dragisha at m3w.org
> > > To: m3devel at elegosoft.com
> > > Date: Wed, 6 Oct 2010 22:40:12 +0200
> > > Subject: [M3devel] static linking of some C libs...
> > >
> > > I would like to statically link only some C libs. How to do it?
> > > --
> > > Dragi?a Duri?
> > >
> >
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 08:21:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 06:21:14 +0000
Subject: [M3devel] gcc 4.5 + AMD64_SOLARIS fyi
In-Reply-To: <COL101-W18C65A5BA10B392652EBDFE66E0@phx.gbl>
References: <COL101-W18C65A5BA10B392652EBDFE66E0@phx.gbl>
Message-ID: <COL101-W48F1E07E8067647F7D42A7E66F0@phx.gbl>


Stupid autoconf just breaks things.

??? gcc_GAS_CHECK_FEATURE([.quad directive],
????? gcc_cv_as_ix86_quad,,,
????? [.quad 0],,
????? [AC_DEFINE(HAVE_AS_IX86_QUAD, 1,
??????? [Define if your assembler supports the .quad directive.])])

added in gcc 4.5 breaks things nicely.
Fix will be to just hardcode  gcc_cv_as_ix86_quad as true in src/m3makefile when doing cross builds to AMD64_SOLARIS.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: gcc 4.5 + AMD64_SOLARIS fyi
> Date: Wed, 6 Oct 2010 23:20:12 +0000
>
>
> m3cc (aka cm3cg) failed compiling: Unicode.mc
> new source -> compiling Address.i3
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
>
>
> occurs in pretty much every file
>
>  - Jay
>
 		 	   		  

From dragisha at m3w.org  Thu Oct  7 09:16:36 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 07 Oct 2010 09:16:36 +0200
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <COL101-W5E9607FC46DFC67A99F8EE66F0@phx.gbl>
References: <1286397612.7401.0.camel@boromir.m3w.org>
	,<COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>
	,<1286431135.7401.13.camel@boromir.m3w.org>
	<COL101-W5E9607FC46DFC67A99F8EE66F0@phx.gbl>
Message-ID: <1286435796.7401.21.camel@boromir.m3w.org>

Of course it's built with Modula-3, and if it's pure C lib - then make a
"placeholder" Modula-3 lib just to keep it "under quake". That way we
will have full control on options, resolving,,, per platform where
differences occur. As opposed to autocrap way and m4 (it's not Modula-4,
don't jump :).

GCC is a hell, and linking "logic" is just a tip of the iceberg. Order
dependency is least of problems. Thus said - I am against Modula-3
linker - our resources are too scarce to fix everything.

import_standalone() would fill static_libs hash, just like import fills
imported_libs, and build_standalone() will just move everything from
imported_libs to static_libs before m3_link continues. Looks clean.

On Thu, 2010-10-07 at 06:13 +0000, Jay K wrote:
> 
> Right.
> What you want something like:
> import_standalone("libfoo")
> or import_static("libfoo")
> 
> shouldn't be too hard.
> Just stick libfoo in some global hashtable and then when linking looks
> for libfoo.so vs. libfoo.a, it can use that to guide.
> 
> That is assuming libfoo is built by Modula-3 and that there are both.
> If it is a C library, you'll have to do something else.
> 
> <rant>
> I find Unix link command lines extremely confusing and very likely
> both
>   having too many and too few features. What with options being in
> effect
> until end of command line, or maybe not, or being able to turn them
> off/on as you go,
> making it all ridiculously order-dependent. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu Oct  7 10:15:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 08:15:39 +0000
Subject: [M3devel] static chain: what does D do?
In-Reply-To: <COL101-W40B78A4BD59FE234DD80F6E66E0@phx.gbl>
References: <20101006090354.BD40E2474003@birch.elegosoft.com>, ,
	<2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu>,
	<COL101-W54E93A9A943E33E99177CCE66E0@phx.gbl>,
	<4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu>,
	<COL101-W40B78A4BD59FE234DD80F6E66E0@phx.gbl>
Message-ID: <COL101-W8344853307806904E5F6AE66F0@phx.gbl>



> > Hmm. Do we know what Pascal/Ada/D and friends do in this instance?
>
>
> Good point. I don't know.

Here is part of the answer:

jbook2:d jay$ grep -i chain p* | grep DEF
patch-apple-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_EXPR, "static_chain_expr", tcc_expression, 1)
patch-apple-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_DECL, "static_chain_decl", tcc_expression, 0)
patch-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_EXPR, "static_chain_expr", tcc_expression, 1)
patch-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_DECL, "static_chain_decl", tcc_expression, 0)
patch-gcc-4.1.x:+ DEFTREECODE (STATIC_CHAIN_EXPR, "static_chain_expr", tcc_expression, 1)
patch-gcc-4.1.x:+ DEFTREECODE (STATIC_CHAIN_DECL, "static_chain_decl", tcc_expression, 0)


interesting.
We had one tree code. They add two.
Their changes are more involved than ours.

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 11:45:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 09:45:49 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
Message-ID: <COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>


Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
I suspect we are underusing volatile.
e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
? The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.

I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
all MODIFY_EXPR. There is probably redundancy here.

Notice that even the original volatization was incomplete.
It volatized current function's current temporaries/locals, but not others declared after
any call to setjmp. I fixed that at some point.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: random notes: gcc 4.5, sparc, etc.
> Date: Wed, 6 Oct 2010 13:30:00 +0000
>
>
> some random notes
>
> Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
>   Easy test is to run cm3 without a neighboring cm3.cfg and the error
>   is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
>
> Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
>   Same easy test, but it crashes upon first attempt to raise an exception.
>
> Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
>   NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
>
> Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
>   Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
>
> Meanwhile I think many other targets are working ok with 4.5.
> Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
>
>  - Jay
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 13:22:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 11:22:28 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>,
	<COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>
Message-ID: <COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>


oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Thu, 7 Oct 2010 09:45:49 +0000
>
>
> Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> I suspect we are underusing volatile.
> e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
>   The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
>
> I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> all MODIFY_EXPR. There is probably redundancy here.
>
> Notice that even the original volatization was incomplete.
> It volatized current function's current temporaries/locals, but not others declared after
> any call to setjmp. I fixed that at some point.
>
>  - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: random notes: gcc 4.5, sparc, etc.
> > Date: Wed, 6 Oct 2010 13:30:00 +0000
> >
> >
> > some random notes
> >
> > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> >
> > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > Same easy test, but it crashes upon first attempt to raise an exception.
> >
> > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> >
> > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> >
> > Meanwhile I think many other targets are working ok with 4.5.
> > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> >
> > - Jay
> >
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 22:02:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 20:02:11 +0000
Subject: [M3devel] Solaris/amd64
Message-ID: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>


There's a complete Solaris/amd64 in /home/jkrell/cm3.amd64 on the opencsw machines having used 4.5.1 backend.
? I can't test the X apps I think (not sure of the remoting).
Would be good to get that in Hudson.

?- Jay


 		 	   		  

From wagner at elegosoft.com  Fri Oct  8 10:28:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 08 Oct 2010 10:28:24 +0200
Subject: [M3devel] Solaris/amd64
In-Reply-To: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
References: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
Message-ID: <20101008102824.61nbtaufk8gowk4s@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> There's a complete Solaris/amd64 in /home/jkrell/cm3.amd64 on the   
> opencsw machines having used 4.5.1 backend.
> ? I can't test the X apps I think (not sure of the remoting).
> Would be good to get that in Hudson.

Is anybody else interested in setting up those jobs? Should not be
difficult, mostly a matter of copy&paste in HTML forms and doing
some one-time bootstrapping to create the necessary directories
and CM3 installations.

It would be great if others acquire some experience with our Hudson
build and regression tests.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Oct  8 13:44:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 11:44:57 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>,
	<COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>,
	<COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>
Message-ID: <COL101-W53AFBBF14A6AC6EA7745F2E6500@phx.gbl>


For the record:
Still, no luck. Replacing MxConfig.ms from 4.3 seems to let it get further.
Or maybe it was M*.
Problem seems to be that when M3File__IsReadable returns, $l7 gets zeroed.

But I'm going to try another hack.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Thu, 7 Oct 2010 11:22:28 +0000
>
>
> oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.
>
>  - Jay
>
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > Date: Thu, 7 Oct 2010 09:45:49 +0000
> >
> >
> > Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> > I suspect we are underusing volatile.
> > e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
> > The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
> >
> > I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> > all MODIFY_EXPR. There is probably redundancy here.
> >
> > Notice that even the original volatization was incomplete.
> > It volatized current function's current temporaries/locals, but not others declared after
> > any call to setjmp. I fixed that at some point.
> >
> > - Jay
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Subject: random notes: gcc 4.5, sparc, etc.
> > > Date: Wed, 6 Oct 2010 13:30:00 +0000
> > >
> > >
> > > some random notes
> > >
> > > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> > >
> > > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > > Same easy test, but it crashes upon first attempt to raise an exception.
> > >
> > > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> > >
> > > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> > >
> > > Meanwhile I think many other targets are working ok with 4.5.
> > > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> > >
> > > - Jay
> > >
> >
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  8 16:17:00 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 08 Oct 2010 16:17:00 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286285550.3514.20.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>
Message-ID: <1286547420.7401.43.camel@boromir.m3w.org>

WindowStar is 
TYPE
  Window = RECORD
    user_data: void_star
  END;
  WindowStar = UNTRACED REF Window;

and this whole record is
typedef struct {
  GdkEventType type;
  GdkWindow *window;
  gint8 send_event;
  guint32 time;
  guint state;
  guint keyval;
  gint length;
  gchar *string;
  guint16 hardware_keycode;
  guint8 group;
  guint is_modifier : 1;
} GdkEventKey;

in C.

It's Modula-3 BYTESIZE is 64, and C sizeof() is 56. window field is aligned at 8 bytes (thank you Jay for m3gap 8_56!) and C's GdkWindow * is aligned at 4 bytes.

As I don't use window field I'll split it in two placeholder int's, but this is, IMO, interesting point.

dd

On Tue, 2010-10-05 at 15:32 +0200, Dragi?a Duri? wrote:
>   EventKey = RECORD 
>     type: EventType;
>     window: WindowStar;
>     send_event: char;
>     time: unsigned_long_int;  
>     state: unsigned_int;
>     keyval: unsigned_int;
>     length: int;
>     string: char_star;
>     hardware_keycode: unsigned_short_int;
>     group: unsigned_char;
>   END;
> 
> also with m3gdb....
> 
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x0,
> send_event = 0 '\000', 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  8 20:36:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 18:36:44 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286547420.7401.43.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>,
	<1286547420.7401.43.camel@boromir.m3w.org>
Message-ID: <COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>


I may have broken this, a while ago. I may have relaxed all the alignments long ago.
We have very little interfacing with C now and most of that is with our own C,
where I avoid small types.
We have had at least temporary problems related to our rules being sort of too strict.
? The need for -munaligned-double or such. (which reminds me I should try that again).
? Where our rules were ok but gcc's default for to align stuff more.
? Where our layout and gcc's didn't agree.

How bad would it be to generate or write a C layer that copies stuff into "idealized" structs?
? Where the types are all INTEGER or LONGINT or pointers.

?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Fri, 8 Oct 2010 16:17:00 +0200
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> WindowStar is
> TYPE
> Window = RECORD
> user_data: void_star
> END;
> WindowStar = UNTRACED REF Window;
>
> and this whole record is
> typedef struct {
> GdkEventType type;
> GdkWindow *window;
> gint8 send_event;
> guint32 time;
> guint state;
> guint keyval;
> gint length;
> gchar *string;
> guint16 hardware_keycode;
> guint8 group;
> guint is_modifier : 1;
> } GdkEventKey;
>
> in C.
>
> It's Modula-3 BYTESIZE is 64, and C sizeof() is 56. window field is aligned at 8 bytes (thank you Jay for m3gap 8_56!) and C's GdkWindow * is aligned at 4 bytes.
>
> As I don't use window field I'll split it in two placeholder int's, but this is, IMO, interesting point.
>
> dd
>
> On Tue, 2010-10-05 at 15:32 +0200, Dragi?a Duri? wrote:
> > EventKey = RECORD
> > type: EventType;
> > window: WindowStar;
> > send_event: char;
> > time: unsigned_long_int;
> > state: unsigned_int;
> > keyval: unsigned_int;
> > length: int;
> > string: char_star;
> > hardware_keycode: unsigned_short_int;
> > group: unsigned_char;
> > END;
> >
> > also with m3gdb....
> >
> > (m3gdb) p event
> > $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> > send_event = 0 '\000',
> --
> Dragi?a Duri? 
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  8 20:46:56 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 08 Oct 2010 20:46:56 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,<1286547420.7401.43.camel@boromir.m3w.org>
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
Message-ID: <1286563617.7401.68.camel@boromir.m3w.org>

We will always have some friction there... IMO, stricter is better, with
maybe a pragma there... preceding variable/field name, fixing align,
like

  EventKey = RECORD
    type: EventType;
    <* ALIGN 4 *> window: WindowStar;
    ...
  END;

As for GCC... Does it not make alignment exception, or something, to
reference non-aligned pointer on AMD64?

Idealized structs... I didn't follow you there, probably I missed
something earlier on list.

On Fri, 2010-10-08 at 18:36 +0000, Jay K wrote:
> I may have broken this, a while ago. I may have relaxed all the
> alignments long ago.
> We have very little interfacing with C now and most of that is with
> our own C,
> where I avoid small types.
> We have had at least temporary problems related to our rules being
> sort of too strict.
>   The need for -munaligned-double or such. (which reminds me I should
> try that again).
>   Where our rules were ok but gcc's default for to align stuff more.
>   Where our layout and gcc's didn't agree.
> 
> How bad would it be to generate or write a C layer that copies stuff
> into "idealized" structs?
>   Where the types are all INTEGER or LONGINT or pointers. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  8 21:00:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 19:00:14 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286563617.7401.68.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, ,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>,
	<1286563617.7401.68.camel@boromir.m3w.org>
Message-ID: <COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>


Idealized is you grow everything to LONGINT or INTEGER and sort by size,
and copy back/forth with C. There will be no padding, guaranteed.

?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 8 Oct 2010 20:46:56 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> We will always have some friction there... IMO, stricter is better, with
> maybe a pragma there... preceding variable/field name, fixing align,
> like
>
> EventKey = RECORD
> type: EventType;
> <* ALIGN 4 *> window: WindowStar;
> ...
> END;
>
> As for GCC... Does it not make alignment exception, or something, to
> reference non-aligned pointer on AMD64?
>
> Idealized structs... I didn't follow you there, probably I missed
> something earlier on list.
>
> On Fri, 2010-10-08 at 18:36 +0000, Jay K wrote:
> > I may have broken this, a while ago. I may have relaxed all the
> > alignments long ago.
> > We have very little interfacing with C now and most of that is with
> > our own C,
> > where I avoid small types.
> > We have had at least temporary problems related to our rules being
> > sort of too strict.
> > The need for -munaligned-double or such. (which reminds me I should
> > try that again).
> > Where our rules were ok but gcc's default for to align stuff more.
> > Where our layout and gcc's didn't agree.
> >
> > How bad would it be to generate or write a C layer that copies stuff
> > into "idealized" structs?
> > Where the types are all INTEGER or LONGINT or pointers.
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Fri Oct  8 21:01:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 19:01:09 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
Message-ID: <COL101-W339845E597D706AF5EEE09E6500@phx.gbl>


Or make all field references be via function calls to C.
Very good option imho.
Like how I access DIR->d_name.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org; m3devel at elegosoft.com
> Subject: RE: [M3devel] m3gap.... it's an alignment issue
> Date: Fri, 8 Oct 2010 18:36:44 +0000
>
>
> I may have broken this, a while ago. I may have relaxed all the alignments long ago.
> We have very little interfacing with C now and most of that is with our own C,
> where I avoid small types.
> We have had at least temporary problems related to our rules being sort of too strict.
>   The need for -munaligned-double or such. (which reminds me I should try that again).
>   Where our rules were ok but gcc's default for to align stuff more.
>   Where our layout and gcc's didn't agree.
>
> How bad would it be to generate or write a C layer that copies stuff into "idealized" structs?
>   Where the types are all INTEGER or LONGINT or pointers.
>
>  - Jay
>
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: m3devel at elegosoft.com
> > Date: Fri, 8 Oct 2010 16:17:00 +0200
> > Subject: Re: [M3devel] m3gap.... it's an alignment issue
> >
> > WindowStar is
> > TYPE
> > Window = RECORD
> > user_data: void_star
> > END;
> > WindowStar = UNTRACED REF Window;
> >
> > and this whole record is
> > typedef struct {
> > GdkEventType type;
> > GdkWindow *window;
> > gint8 send_event;
> > guint32 time;
> > guint state;
> > guint keyval;
> > gint length;
> > gchar *string;
> > guint16 hardware_keycode;
> > guint8 group;
> > guint is_modifier : 1;
> > } GdkEventKey;
> >
> > in C.
> >
> > It's Modula-3 BYTESIZE is 64, and C sizeof() is 56. window field is aligned at 8 bytes (thank you Jay for m3gap 8_56!) and C's GdkWindow * is aligned at 4 bytes.
> >
> > As I don't use window field I'll split it in two placeholder int's, but this is, IMO, interesting point.
> >
> > dd
> >
> > On Tue, 2010-10-05 at 15:32 +0200, Dragi?a Duri? wrote:
> > > EventKey = RECORD
> > > type: EventType;
> > > window: WindowStar;
> > > send_event: char;
> > > time: unsigned_long_int;
> > > state: unsigned_int;
> > > keyval: unsigned_int;
> > > length: int;
> > > string: char_star;
> > > hardware_keycode: unsigned_short_int;
> > > group: unsigned_char;
> > > END;
> > >
> > > also with m3gdb....
> > >
> > > (m3gdb) p event
> > > $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> > > send_event = 0 '\000',
> > --
> > Dragi?a Duri?
> >
>
 		 	   		  

From jay.krell at cornell.edu  Fri Oct  8 21:03:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 19:03:19 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286563617.7401.68.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, ,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>,
	<1286563617.7401.68.camel@boromir.m3w.org>
Message-ID: <COL101-W63F9F601EF463A07A12CE1E6500@phx.gbl>


Gcc does nothing special. There are "never" alignment exceptions on x86.
? Things might run slower. There is a control bit in the processor to make
? it more strict but surely nobody sets it.
? Some interlocked and maybe sse/sse2/3/4 intructions have alignment requirements.
?We either have to go pains to match it precisely, and have silent memory
? corruption if we fail. Or give up and don't really try.
By relaxed I meant larger alignments. You might call this more strict.

?- Jay


----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 8 Oct 2010 20:46:56 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> We will always have some friction there... IMO, stricter is better, with
> maybe a pragma there... preceding variable/field name, fixing align,
> like
>
> EventKey = RECORD
> type: EventType;
> <* ALIGN 4 *> window: WindowStar;
> ...
> END;
>
> As for GCC... Does it not make alignment exception, or something, to
> reference non-aligned pointer on AMD64?
>
> Idealized structs... I didn't follow you there, probably I missed
> something earlier on list.
>
> On Fri, 2010-10-08 at 18:36 +0000, Jay K wrote:
> > I may have broken this, a while ago. I may have relaxed all the
> > alignments long ago.
> > We have very little interfacing with C now and most of that is with
> > our own C,
> > where I avoid small types.
> > We have had at least temporary problems related to our rules being
> > sort of too strict.
> > The need for -munaligned-double or such. (which reminds me I should
> > try that again).
> > Where our rules were ok but gcc's default for to align stuff more.
> > Where our layout and gcc's didn't agree.
> >
> > How bad would it be to generate or write a C layer that copies stuff
> > into "idealized" structs?
> > Where the types are all INTEGER or LONGINT or pointers.
> --
> Dragi?a Duri? 
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  8 21:06:37 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 08 Oct 2010 21:06:37 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W339845E597D706AF5EEE09E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,<1286547420.7401.43.camel@boromir.m3w.org>
	,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	<COL101-W339845E597D706AF5EEE09E6500@phx.gbl>
Message-ID: <1286564797.7401.70.camel@boromir.m3w.org>

Not a bad idea, if we are generating wrapper code... To write all that
by hand... I am shuddering at thought :)

On Fri, 2010-10-08 at 19:01 +0000, Jay K wrote:
> 
> Or make all field references be via function calls to C.
> Very good option imho.
> Like how I access DIR->d_name. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sat Oct  9 23:53:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Oct 2010 21:53:18 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>, ,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>,
	<1286563617.7401.68.camel@boromir.m3w.org>,
	<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
Message-ID: <COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>


> Idealized is you grow everything to LONGINT or INTEGER and sort by size,
> and copy back/forth with C. There will be no padding, guaranteed.

I sort of made up these rules btw, and then sort alphabetically.
And for good measure, during initialization, you can
pass a value or var/pointer of one of these structs to/from
C/Modula-3 and assert on the other side that it looks as expected.
 
 
For example:
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/TestC.c
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/Test.i3
  "CheckFloatsAndTypes"
 
I couldn't find where I call it.
I would be reasonble imho to put in m3core.
 Though the float stuff should be better thought out to have
  a complete but no extra test.
Maybe even passed from main to RTLinker.InitRuntime.
 
This is also done in:
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosixC.c
  function TypeCheck
 
 
To make sure the C and Modula-3 line up.
Note this isn't with "underlying C", but with our own C.
I moved things up a layer to avoid extra copying of struct tm,
and so I could #ifdef the 2 almost identical implementations into one.
 
 
 - Jay 		 	   		  

From dragisha at m3w.org  Sun Oct 10 01:50:43 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 10 Oct 2010 01:50:43 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,,<1286547420.7401.43.camel@boromir.m3w.org>
	,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	,<1286563617.7401.68.camel@boromir.m3w.org>
	,<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
	<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
Message-ID: <1286668243.7401.79.camel@boromir.m3w.org>

Eliminating key phrase being "out own C"...

I understand your approach here, and it's all OK - except it means ultra
extra work for large APIs like Gtk+ I am working with/on. To accomplish
things in our lifetimes, we have to automate things. It all boils down
to "parse .h somehow, and then manipulate AST's to produce pieces of C
and pieces of Modula-3". 

Looks a lot what SWIG does already, and I think it's nice place to
start. Get what they already learned from .h's and produce better
interfacing libraries. More concise and readable, at least.

On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> 
> Note this isn't with "underlying C", but with our own C. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sun Oct 10 08:52:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Oct 2010 06:52:49 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286668243.7401.79.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, , ,
	<1286547420.7401.43.camel@boromir.m3w.org>, ,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>, ,
	<1286563617.7401.68.camel@boromir.m3w.org>, ,
	<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>,
	<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>,
	<1286668243.7401.79.camel@boromir.m3w.org>
Message-ID: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>


Look at what others do?
 
Heck there is a C# binding. You can compile that
and reflect over its metadata.. should be able
to spit back out the original C headers?
 
 
Just Bing for "automate gtk binding"?
 
http://pwet.fr/man/linux/commandes/generate2
http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#autogeneration
 
etc.
 
Someone should make an interface language, that everyone
actually uses!
 
 - Jay



----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Sun, 10 Oct 2010 01:50:43 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> Eliminating key phrase being "out own C"...
>
> I understand your approach here, and it's all OK - except it means ultra
> extra work for large APIs like Gtk+ I am working with/on. To accomplish
> things in our lifetimes, we have to automate things. It all boils down
> to "parse .h somehow, and then manipulate AST's to produce pieces of C
> and pieces of Modula-3".
>
> Looks a lot what SWIG does already, and I think it's nice place to
> start. Get what they already learned from .h's and produce better
> interfacing libraries. More concise and readable, at least.
>
> On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> >
> > Note this isn't with "underlying C", but with our own C.
> --
> Dragi?a Duri? 
> 		 	   		  

From jay.krell at cornell.edu  Sun Oct 10 08:55:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Oct 2010 06:55:41 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>, , ,
	<1286547420.7401.43.camel@boromir.m3w.org>, ,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>, ,
	<1286563617.7401.68.camel@boromir.m3w.org>, ,
	<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>,
	<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>,
	<1286668243.7401.79.camel@boromir.m3w.org>,
	<COL101-W5840291BB9D967149038BBE6520@phx.gbl>
Message-ID: <COL101-W25D903D0121B17997EDFEEE6520@phx.gbl>


get gtk.defs from pygtk.
 
or
"It's worth noting that the "new way" to do things is with
gobject-introspection rather than a defs file (see pybank, gjs)"
 
etc.
 
 
 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] m3gap.... it's an alignment issue
> Date: Sun, 10 Oct 2010 06:52:49 +0000
>
>
> Look at what others do?
>
> Heck there is a C# binding. You can compile that
> and reflect over its metadata.. should be able
> to spit back out the original C headers?
>
>
> Just Bing for "automate gtk binding"?
>
> http://pwet.fr/man/linux/commandes/generate2
> http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#autogeneration
>
> etc.
>
> Someone should make an interface language, that everyone
> actually uses!
>
> - Jay
>
>
>
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: jay.krell at cornell.edu
> > Date: Sun, 10 Oct 2010 01:50:43 +0200
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] m3gap.... it's an alignment issue
> >
> > Eliminating key phrase being "out own C"...
> >
> > I understand your approach here, and it's all OK - except it means ultra
> > extra work for large APIs like Gtk+ I am working with/on. To accomplish
> > things in our lifetimes, we have to automate things. It all boils down
> > to "parse .h somehow, and then manipulate AST's to produce pieces of C
> > and pieces of Modula-3".
> >
> > Looks a lot what SWIG does already, and I think it's nice place to
> > start. Get what they already learned from .h's and produce better
> > interfacing libraries. More concise and readable, at least.
> >
> > On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> > >
> > > Note this isn't with "underlying C", but with our own C.
> > --
> > Dragi?a Duri?
> > 		 	   		  

From dragisha at m3w.org  Sun Oct 10 09:30:19 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 10 Oct 2010 09:30:19 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,,,<1286547420.7401.43.camel@boromir.m3w.org>
	,,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	,,<1286563617.7401.68.camel@boromir.m3w.org>
	,,<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
	,<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
	,<1286668243.7401.79.camel@boromir.m3w.org>
	<COL101-W5840291BB9D967149038BBE6520@phx.gbl>
Message-ID: <1286695819.7401.88.camel@boromir.m3w.org>

Of course... And I found lots of them uses regexp "parsers"... All
making same mistakes du to an EOL too many. No silver bullet there, but
even if there is one - Gtk+ is one example.

More important library (for me, of course) I am looking at is ffmpeg.
And few others. And their bindingness is not long enough present problem
to be as widely approached as Gtk+ is. 

On Sun, 2010-10-10 at 06:52 +0000, Jay K wrote:
> Look at what others do?
>  
> Heck there is a C# binding. You can compile that
> and reflect over its metadata.. should be able
> to spit back out the original C headers?
>  
> 
> Just Bing for "automate gtk binding"?
>  
> http://pwet.fr/man/linux/commandes/generate2
> http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#autogeneration
>  
> etc.
>  
> Someone should make an interface language, that everyone
> actually uses!
>  
>  - Jay
> 
> 
> 
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: jay.krell at cornell.edu
> > Date: Sun, 10 Oct 2010 01:50:43 +0200
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] m3gap.... it's an alignment issue
> >
> > Eliminating key phrase being "out own C"...
> >
> > I understand your approach here, and it's all OK - except it means ultra
> > extra work for large APIs like Gtk+ I am working with/on. To accomplish
> > things in our lifetimes, we have to automate things. It all boils down
> > to "parse .h somehow, and then manipulate AST's to produce pieces of C
> > and pieces of Modula-3".
> >
> > Looks a lot what SWIG does already, and I think it's nice place to
> > start. Get what they already learned from .h's and produce better
> > interfacing libraries. More concise and readable, at least.
> >
> > On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> > >
> > > Note this isn't with "underlying C", but with our own C.
> > --
> > Dragi?a Duri? 
> > 		 	   		  

-- 
Dragi?a Duri? <dragisha at m3w.org>



From dragisha at m3w.org  Sun Oct 10 09:31:38 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 10 Oct 2010 09:31:38 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,,,<1286547420.7401.43.camel@boromir.m3w.org>
	,,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	,,<1286563617.7401.68.camel@boromir.m3w.org>
	,,<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
	,<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
	,<1286668243.7401.79.camel@boromir.m3w.org>
	<COL101-W5840291BB9D967149038BBE6520@phx.gbl>
Message-ID: <1286695898.7401.89.camel@boromir.m3w.org>

Someone was, many times. But that didn't catch due to "It works, let's
go on" philosophy many schools are teaching.

On Sun, 2010-10-10 at 06:52 +0000, Jay K wrote:
> Someone should make an interface language, that everyone
> actually uses!
>   
-- 
Dragi?a Duri? <dragisha at m3w.org>



From dam at opencsw.org  Mon Oct 11 21:41:48 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 11 Oct 2010 21:41:48 +0200
Subject: [M3devel] Solaris/amd64
In-Reply-To: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
References: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
Message-ID: <6BC12B5F-5751-4F32-AA6E-8BC5FB8B0304@opencsw.org>

Hi Jay,

Am 07.10.2010 um 22:02 schrieb Jay K:
> There's a complete Solaris/amd64 in /home/jkrell/cm3.amd64 on the  
> opencsw machines having used 4.5.1 backend.
>   I can't test the X apps I think (not sure of the remoting).

Did I set up SSGD (X11-over-https) for you? This should make
redirection easy:
   https://sgd.opencsw.org


Best regards

   -- Dago




From jay.krell at cornell.edu  Tue Oct 12 00:35:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 11 Oct 2010 22:35:29 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W53AFBBF14A6AC6EA7745F2E6500@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>,
	<COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>,
	<COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>,
	<COL101-W53AFBBF14A6AC6EA7745F2E6500@phx.gbl>
Message-ID: <COL101-W63F21716075DE7A992C65CE6530@phx.gbl>


This is a really tough one to figure out.
I've tried making everything as returns_twice. No luck.
I'm not doing any optimization anyway.
  Though it looks like some optimizations might be done anyway,
  like converting jumps to jumps to single jump.
  I did some work to make 4.3 and 4.5 match, but not completely, and no luck so far.
 
 
I believe the problem isn't MxConfig per se. It is just that the 4.3
version doesn't use $l7 after calling M3File__IsReadable, so
is ok if $l7 isn't restored correctly.
 
 
I have to figure out, perhaps, where save/restore/return/ta3 store/load
the registers from and if that is getting corrupt.
I had trouble finding details on the SPARC stuff. (too much skimming by me) 
e.g. that the register windows are 16 registers in size,
that every non-leaf function must therefore have a frame of at least 64 bytes.
Er, the windows are actually 24 in size, but they overlap by 8, so 16 registers
might be saved/restored at each frame.
(Aside: I believe one of the flaws here is not register windows per se, but
fixed size register windows; I believe Itanium has effectively
variably sized register windows).
 
 
There's still stuff I don't understand -- how setjmp/longjmp/setcontext work.
 wrt SPARC specifically. I understand them otherwise.
 In a CS class in college I was actually tricked on a test by
 the "implement setjmp/longjmp for SPARC" question. I had implemented
 setjmp/longjmp for 65816 so I was overconfident, and just
 did simple register save/load. The trick at the time
 was explained to be "restore in a loop until the register window
 lines up". However that's not how SPARC longjmp looks wherever I checked
 in the past few days.
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Fri, 8 Oct 2010 11:44:57 +0000
>
>
> For the record:
> Still, no luck. Replacing MxConfig.ms from 4.3 seems to let it get further.
> Or maybe it was M*.
> Problem seems to be that when M3File__IsReadable returns, $l7 gets zeroed.
>
> But I'm going to try another hack.
>
> - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > Date: Thu, 7 Oct 2010 11:22:28 +0000
> >
> >
> > oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.
> >
> > - Jay
> >
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > > Date: Thu, 7 Oct 2010 09:45:49 +0000
> > >
> > >
> > > Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> > > I suspect we are underusing volatile.
> > > e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
> > > The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
> > >
> > > I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> > > all MODIFY_EXPR. There is probably redundancy here.
> > >
> > > Notice that even the original volatization was incomplete.
> > > It volatized current function's current temporaries/locals, but not others declared after
> > > any call to setjmp. I fixed that at some point.
> > >
> > > - Jay
> > >
> > > ----------------------------------------
> > > > From: jay.krell at cornell.edu
> > > > To: m3devel at elegosoft.com
> > > > Subject: random notes: gcc 4.5, sparc, etc.
> > > > Date: Wed, 6 Oct 2010 13:30:00 +0000
> > > >
> > > >
> > > > some random notes
> > > >
> > > > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > > > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > > > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> > > >
> > > > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > > > Same easy test, but it crashes upon first attempt to raise an exception.
> > > >
> > > > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > > > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> > > >
> > > > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > > > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> > > >
> > > > Meanwhile I think many other targets are working ok with 4.5.
> > > > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> > > >
> > > > - Jay
> > > >
> > >
> >
> 		 	   		  

From jay.krell at cornell.edu  Wed Oct 13 11:48:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Oct 2010 09:48:44 +0000
Subject: [M3devel] stack walker vs. gcc 4.5
Message-ID: <COL101-W4428AF300D518BD4AA4D5FE6550@phx.gbl>


I'm really really really really really really inclined to ditch using the one stack walker we use: SOLgnu/SOLsun/SPARC32_SOLARIS.
?I have been trying for quite a while to get it to work with the gcc 4.5 backend with no luck.


We could/should use the gcc exception handling support, thereby getting stack walking for most/all platforms.


Though odds are probably higher of generating C++ source and using exception handling there, and again, getting stack walking.
? (Or C on VMS/NT/OSF1 since they all have exception handling in C; NT/x86 doesn't really do stack walking, but
an optimized form of our non-stackwalking implementation)


?- Jay

 		 	   		  

From hosking at cs.purdue.edu  Wed Oct 13 16:56:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Oct 2010 10:56:34 -0400
Subject: [M3devel] stack walker vs. gcc 4.5
In-Reply-To: <COL101-W4428AF300D518BD4AA4D5FE6550@phx.gbl>
References: <COL101-W4428AF300D518BD4AA4D5FE6550@phx.gbl>
Message-ID: <F0708FBD-7C63-48CB-97BF-DE321B69EDBC@cs.purdue.edu>

Yes, agreed we should use gcc exception handling support.  It should not be that hard to use their stack walker.

On 13 Oct 2010, at 05:48, Jay K wrote:

> 
> I'm really really really really really really inclined to ditch using the one stack walker we use: SOLgnu/SOLsun/SPARC32_SOLARIS.
>  I have been trying for quite a while to get it to work with the gcc 4.5 backend with no luck.
> 
> 
> We could/should use the gcc exception handling support, thereby getting stack walking for most/all platforms.
> 
> 
> Though odds are probably higher of generating C++ source and using exception handling there, and again, getting stack walking.
>   (Or C on VMS/NT/OSF1 since they all have exception handling in C; NT/x86 doesn't really do stack walking, but
> an optimized form of our non-stackwalking implementation)
> 
> 
>  - Jay
> 
> 		 	   		  



From dabenavidesd at yahoo.es  Wed Oct 13 21:34:13 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 13 Oct 2010 20:34:13 +0100 (BST)
Subject: [M3devel] stack walker vs. gcc 4.5
In-Reply-To: <F0708FBD-7C63-48CB-97BF-DE321B69EDBC@cs.purdue.edu>
Message-ID: <79057.93087.qm@web29710.mail.ird.yahoo.com>

Hi all:
I was wondering what is about the Ultrix 4.3 bsd based stack walker and backend for the dec mips based ds3100. Should be a good thing to have some sort of restoration project team in that. Besides that, Utltrix source is publicly available now.
Just in case let me know who knows if anybody wants to look at it.
Thanks in advance 

--- El mi?, 13/10/10, Tony Hosking <hosking at cs.purdue.edu> escribi?:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] stack walker vs. gcc 4.5
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 13 de octubre, 2010 09:56
> Yes, agreed we should use gcc
> exception handling support.  It should not be that hard
> to use their stack walker.
> 
> On 13 Oct 2010, at 05:48, Jay K wrote:
> 
> > 
> > I'm really really really really really really inclined
> to ditch using the one stack walker we use:
> SOLgnu/SOLsun/SPARC32_SOLARIS.
> >  I have been trying for quite a while to get it
> to work with the gcc 4.5 backend with no luck.
> > 
> > 
> > We could/should use the gcc exception handling
> support, thereby getting stack walking for most/all
> platforms.
> > 
> > 
> > Though odds are probably higher of generating C++
> source and using exception handling there, and again,
> getting stack walking.
> >   (Or C on VMS/NT/OSF1 since they all
> have exception handling in C; NT/x86 doesn't really do stack
> walking, but
> > an optimized form of our non-stackwalking
> implementation)
> > 
> > 
> >  - Jay
> > 
> >    
>         
>           
>   
> 
> 


      


From jay.krell at cornell.edu  Thu Oct 14 05:56:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Oct 2010 03:56:18 +0000
Subject: [M3devel] my hudson nodes
Message-ID: <COL101-W3160FCBFC0EC1688099F33E6560@phx.gbl>


Nearly all of my Hudson nodes are down for now.
Maybe indefinitely.
Or will bring back only x86/AMD64 as VMs.
?(no Linux/sparc, Linux/powerpc, Solaris/sparc, but
we have Solaris/sparc otherwise, the rest are minor,
and others might rehost them at some point, or
I might)


?- Jay
 		 	   		  

From wagner at elegosoft.com  Thu Oct 14 09:56:17 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Oct 2010 09:56:17 +0200
Subject: [M3devel] my hudson nodes
Message-ID: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Nearly all of my Hudson nodes are down for now.
> Maybe indefinitely.
> Or will bring back only x86/AMD64 as VMs.
> ?(no Linux/sparc, Linux/powerpc, Solaris/sparc, but
> we have Solaris/sparc otherwise, the rest are minor,
> and others might rehost them at some point, or
> I might)

Hi Jay,

I feared as much when you offered all your hardware some time ago.
I didn't contact you then because I don't think it would make sense to
ship some of the machines to our offices in Europe (too expensive).

I think especially the xdarwin and xlinux nodes are still of interest
for M3 users. Perhaps somebody else can host those platforms?

Anyway, thank you very much for providing those build and test machines
for the recent years. I hope you just clear up the hardware zoo at your
home and don't plan to give up the work on M3 in general.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney_bates at lcwb.coop  Thu Oct 14 17:05:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 14 Oct 2010 10:05:46 -0500
Subject: [M3devel] my hudson nodes
In-Reply-To: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>
References: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>
Message-ID: <4CB71C4A.2050904@lcwb.coop>



Olaf Wagner wrote:
> Quoting Jay K <jay.krell at cornell.edu>:
> 
>> Nearly all of my Hudson nodes are down for now.
>> Maybe indefinitely.
>> Or will bring back only x86/AMD64 as VMs.
>>  (no Linux/sparc, Linux/powerpc, Solaris/sparc, but
>> we have Solaris/sparc otherwise, the rest are minor,
>> and others might rehost them at some point, or
>> I might)
> 
> Hi Jay,
> 
> I feared as much when you offered all your hardware some time ago.
> I didn't contact you then because I don't think it would make sense to
> ship some of the machines to our offices in Europe (too expensive).
> 
> I think especially the xdarwin and xlinux nodes are still of interest
> for M3 users. Perhaps somebody else can host those platforms?

If/when I manage to get a better internet connection, I could host a few.
Right now, I'm stuck with a satellite connection which, aside from being
somewhat slow on bit rate and absolutely glacial on latency, has draconian
bit quotas, both up and down.  And they slow it down a whole lot more if I
exceed them.  It's the only drawback to living out in tallgrass prairie,
which is in all other respects, wonderful.  I continue to work on
alternatives.

> 
> Anyway, thank you very much for providing those build and test machines
> for the recent years. I hope you just clear up the hardware zoo at your
> home and don't plan to give up the work on M3 in general.
> 
> Olaf


From jay.krell at cornell.edu  Thu Oct 14 23:24:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Oct 2010 21:24:14 +0000
Subject: [M3devel] my hudson nodes
In-Reply-To: <4CB71C4A.2050904@lcwb.coop>
References: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>,
	<4CB71C4A.2050904@lcwb.coop>
Message-ID: <COL101-W292F0316E8E53E567884DFE6560@phx.gbl>


xdarwin is a laptop I use regularly. It will stay. It isn't always on.
xlinux is also a laptop and is among first in line to come back or be replaced with a VM on xdarwin.
The vast majority of my hardware has never been Hudson nodes.
But yes it is related.

?- Jay


----------------------------------------
> Date: Thu, 14 Oct 2010 10:05:46 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] my hudson nodes
>
>
>
> Olaf Wagner wrote:
> > Quoting Jay K :
> >
> >> Nearly all of my Hudson nodes are down for now.
> >> Maybe indefinitely.
> >> Or will bring back only x86/AMD64 as VMs.
> >> (no Linux/sparc, Linux/powerpc, Solaris/sparc, but
> >> we have Solaris/sparc otherwise, the rest are minor,
> >> and others might rehost them at some point, or
> >> I might)
> >
> > Hi Jay,
> >
> > I feared as much when you offered all your hardware some time ago.
> > I didn't contact you then because I don't think it would make sense to
> > ship some of the machines to our offices in Europe (too expensive).
> >
> > I think especially the xdarwin and xlinux nodes are still of interest
> > for M3 users. Perhaps somebody else can host those platforms?
>
> If/when I manage to get a better internet connection, I could host a few.
> Right now, I'm stuck with a satellite connection which, aside from being
> somewhat slow on bit rate and absolutely glacial on latency, has draconian
> bit quotas, both up and down. And they slow it down a whole lot more if I
> exceed them. It's the only drawback to living out in tallgrass prairie,
> which is in all other respects, wonderful. I continue to work on
> alternatives.
>
> >
> > Anyway, thank you very much for providing those build and test machines
> > for the recent years. I hope you just clear up the hardware zoo at your
> > home and don't plan to give up the work on M3 in general.
> >
> > Olaf
 		 	   		  

From michael.anderson at elego.de  Fri Oct 15 12:05:18 2010
From: michael.anderson at elego.de (Michael Anderson)
Date: Fri, 15 Oct 2010 12:05:18 +0200
Subject: [M3devel] [elego Server Maintenance] Friday 15.10.2010 20:00
Message-ID: <20101015120518.8q3kbjqmo88kkwoo@mail.elegosoft.com>

Hello,

On Friday, October 15 at 8 PM CEST, we will perform scheduled
maintenance on our servers.
Brief interruptions of service may occur.
Expected duration: 120 Min.

We apologize for any inconvenience.

- the elego Admins


-- 
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194




From jay.krell at cornell.edu  Sat Oct 16 14:18:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Oct 2010 12:18:53 +0000
Subject: [M3devel] bootstrapping wrinkle,
 incrementality bug when toggling build_standalone
Message-ID: <COL101-W11D13E1A83111DB860A770E6580@phx.gbl>


I found a new bootstrapping wrinkle tonight.
Based on that we typically have pairs of libraries:
NT: foo.lib, foo.lib.sa
Posix: libfoo.a, libfoo.a.sa?
 
 
If there is incompatibility introduced in m3core,
such as I introduced just now for set_member/set_singleton,
it *seems* you can get into a situation where only
one of the two libraries is updated.
 
 
Perhaps because I was hacking shared = false, perhaps
to workaround other problems.
 
 
Anyway, the general technique might be useful.
 ==> move foo.lib.sa to foo.lib
 
 
More generally there IS an obvious problem in the system.
IF I have a library that was previously not standalone,
therefore having both foo.lib and foo.lib.sa,
 
 
and then I change it to always be standalone,
therefore only having foo.lib,
 
 
and then I link a standalone application to it,
the out of date foo.lib.sa will be found and used.
 
 
Solutions include:
 - when shipping, delete related neighboring files.
   i.e. when shipping a non-standalone library, delete the shipped foo.lib.sa.
 - or, always make foo.lib and foo.lib.sa, just that
   they might be identical.
 - or, lame...probe contents not name? if foo.lib appears to be
   standalone, don't probe for foo.lib.sa? Not difficult on NT...
 
 
(This goes to show something I can never very well explain why:
file existance checks, probes, generally indicate problems.)
 
 
 - Jay
  		 	   		  

From jay.krell at cornell.edu  Sun Oct 17 02:27:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Oct 2010 00:27:11 +0000
Subject: [M3devel] firming up atomics?
Message-ID: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>


Tony,

Can we firm up the atomic semantics/implementatino?

Now might be a good time for me to make the NT/x86 backend
definitely work, test it, and make it more efficient.
? (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
?
?
Like, old value vs. new value returned?


Off the cuff, I'd say, better to always return old value.
The new value can always be computed from it.

However we are the mercy of the processors.


And it only matters for or/and.
xor/add/sub/inc/dec can all compute either from either.


Also, please, I don't find the specifications clear.
At least the last time I studied them.


To me they should say, things like,
?"returns the old value" 
?or "returns the new value" 

?
or returns true if compare matched
or returns false if the compare matched
etc.


The mentions of "spurious failure" or whatnot didn't make sense either.
They should say, something like:
returns true if the compare matched
?but sometimes even if the compare should have matched,
?it won't, and false will be returned -- specify everything that happens when there is "failure".

?
Furthermore, if you look at what Microsoft compilers provide,
they provide a bunch of very simple very clear well documented functions,
that the compiler implements and inlines.
?(at least if you ignore the qcuire/release stuff that confuses me...


You could specify in terms of them.
?Really. A good idea.


ie: is our compare_exchange equivalent to InterlockedCompareExchange?
? Or maybe parameter order different?

? 
Of course, I understand, the types supported by the Microsoft
intrinsics have varied through time and slowly grown.
8bit and 16bit might still be lacking but 32bit and 64bit are very
complete. 64bit atomic operations on 32bit x86 processors 
since Pentium or so can be synthesized with a loop over
InterlockedCompareExchange64.


Or in terms of the gcc intrinsics, probably similarly ok.


We should probably also nail down the implementation where
they aren't available.


And maybe put in safer defaults?
? And quickly improve where we can, e.g. on all x86/AMD64 platforms.
? 

?Thanks,
?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Sun Oct 17 14:48:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Oct 2010 08:48:09 -0400
Subject: [M3devel] firming up atomics?
In-Reply-To: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>
References: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>
Message-ID: <FF060A4B-7136-4FA7-89BB-712B96FC710B@cs.purdue.edu>

I still have some fixes to check in before turning it on again.
They are intended to match the approved C++0x standard.

On 16 Oct 2010, at 20:27, Jay K wrote:

> 
> Tony,
> 
> Can we firm up the atomic semantics/implementatino?
> 
> Now might be a good time for me to make the NT/x86 backend
> definitely work, test it, and make it more efficient.
>   (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
>  
>  
> Like, old value vs. new value returned?
> 
> 
> Off the cuff, I'd say, better to always return old value.
> The new value can always be computed from it.
> 
> However we are the mercy of the processors.
> 
> 
> And it only matters for or/and.
> xor/add/sub/inc/dec can all compute either from either.
> 
> 
> Also, please, I don't find the specifications clear.
> At least the last time I studied them.
> 
> 
> To me they should say, things like,
>  "returns the old value" 
>  or "returns the new value" 
> 
>  
> or returns true if compare matched
> or returns false if the compare matched
> etc.
> 
> 
> The mentions of "spurious failure" or whatnot didn't make sense either.
> They should say, something like:
> returns true if the compare matched
>  but sometimes even if the compare should have matched,
>  it won't, and false will be returned -- specify everything that happens when there is "failure".
> 
>  
> Furthermore, if you look at what Microsoft compilers provide,
> they provide a bunch of very simple very clear well documented functions,
> that the compiler implements and inlines.
>  (at least if you ignore the qcuire/release stuff that confuses me...
> 
> 
> You could specify in terms of them.
>  Really. A good idea.
> 
> 
> ie: is our compare_exchange equivalent to InterlockedCompareExchange?
>   Or maybe parameter order different?
> 
>   
> Of course, I understand, the types supported by the Microsoft
> intrinsics have varied through time and slowly grown.
> 8bit and 16bit might still be lacking but 32bit and 64bit are very
> complete. 64bit atomic operations on 32bit x86 processors 
> since Pentium or so can be synthesized with a loop over
> InterlockedCompareExchange64.
> 
> 
> Or in terms of the gcc intrinsics, probably similarly ok.
> 
> 
> We should probably also nail down the implementation where
> they aren't available.
> 
> 
> And maybe put in safer defaults?
>   And quickly improve where we can, e.g. on all x86/AMD64 platforms.
>   
> 
>  Thanks,
>  - Jay
> 		 	   		  



From ttmrichter at gmail.com  Mon Oct 18 19:08:07 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Tue, 19 Oct 2010 01:08:07 +0800
Subject: [M3devel] CM3, Windows and GCC
Message-ID: <AANLkTikK=HwxCsGtpHSe__KzNWOzjg54a0v8pwocU=WM@mail.gmail.com>

Is there any way through, say, MinGW (or, if absolutely necessary, Cygwin)
to get the back-end for CM3 to target GCC on Windows instead of Microsoft's
tool chain?

-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101019/c425ee8e/attachment.html>

From jay.krell at cornell.edu  Tue Oct 19 08:48:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 19 Oct 2010 06:48:32 +0000
Subject: [M3devel] firming up atomics?
In-Reply-To: <FF060A4B-7136-4FA7-89BB-712B96FC710B@cs.purdue.edu>
References: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>,
	<FF060A4B-7136-4FA7-89BB-712B96FC710B@cs.purdue.edu>
Message-ID: <COL101-W40DE4DFA20016824C36938E65B0@phx.gbl>


Tony, hm, the full generality, in the backend, I think it should be a parameter whether or not the old value or new value or both or neither are returned.
 
See how the Microsoft intrinsics return the old value, but the x86 instructions return the new value, necessitating compare/exchange loops, unless the value is ignored, in which case much more efficient:
 
"v" for void:
 
void __fastcall vor(long a, long b) { _InterlockedOr(a, b); }
long __fastcall or(long a, long b) { return _InterlockedOr(a, b); }
 
void __fastcall vxor(long a, long b) { _InterlockedXor(a, b); }
long __fastcall xor(long a, long b) { return _InterlockedXor(a, b); }
 
void __fastcall vand(long a, long b) { _InterlockedAnd(a, b); }
long __fastcall and(long a, long b) { return _InterlockedAnd(a, b); }

 
C:\>cl -c 1.c -FAsc -Ox && more 1.cod

; 3    : void __fastcall vor(long a, long b) { _InterlockedOr(a, b); }
  00000 f0 09 11         lock     or     DWORD PTR [ecx], edx
  00003 c3               ret     0

; 4    : long __fastcall or(long a, long b) { return _InterlockedOr(a, b); }
  00010 56               push    esi
  00011 8b 01            mov     eax, DWORD PTR [ecx]
$LN3@:
  00013 8b f0            mov     esi, eax
  00015 0b f2            or      esi, edx
  00017 f0 0f b1 31      lock     cmpxchg DWORD PTR [ecx], esi
  0001b 75 f6            jne     SHORT $LN3@
  0001d 5e               pop     esi
  0001e c3               ret     0

 
; 6    : void __fastcall vxor(long a, long b) { _InterlockedXor(a, b); }
  00020 f0 31 11         lock     xor    DWORD PTR [ecx], edx
  00023 c3               ret     0

 
; 7    : long __fastcall xor(long a, long b) { return _InterlockedXor(a, b); }
  00030 56               push    esi
  00031 8b 01            mov     eax, DWORD PTR [ecx]
$LN3@:
  00033 8b f0            mov     esi, eax
  00035 33 f2            xor     esi, edx
  00037 f0 0f b1 31      lock     cmpxchg DWORD PTR [ecx], esi
  0003b 75 f6            jne     SHORT $LN3@
  0003d 5e               pop     esi
  0003e c3               ret     0

 
; 9    : void __fastcall vand(long a, long b) { _InterlockedAnd(a, b); }
  00040 f0 21 11         lock     and    DWORD PTR [ecx], edx
  00043 c3               ret     0

 
; 10   : long __fastcall and(long a, long b) { return _InterlockedAnd(a, b); }
  00050 56               push    esi
  00051 8b 01            mov     eax, DWORD PTR [ecx]
$LN3@:
  00053 8b f0            mov     esi, eax
  00055 23 f2            and     esi, edx
  00057 f0 0f b1 31      lock     cmpxchg DWORD PTR [ecx], esi
  0005b 75 f6            jne     SHORT $LN3@
  0005d 5e               pop     esi
  0005e c3               ret     0
@and at 8  ENDP
_TEXT   ENDS
END
 
 
 - Jay


 
> Subject: Re: [M3devel] firming up atomics?
> From: hosking at cs.purdue.edu
> Date: Sun, 17 Oct 2010 08:48:09 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I still have some fixes to check in before turning it on again.
> They are intended to match the approved C++0x standard.
> 
> On 16 Oct 2010, at 20:27, Jay K wrote:
> 
> > 
> > Tony,
> > 
> > Can we firm up the atomic semantics/implementatino?
> > 
> > Now might be a good time for me to make the NT/x86 backend
> > definitely work, test it, and make it more efficient.
> > (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
> > 
> > 
> > Like, old value vs. new value returned?
> > 
> > 
> > Off the cuff, I'd say, better to always return old value.
> > The new value can always be computed from it.
> > 
> > However we are the mercy of the processors.
> > 
> > 
> > And it only matters for or/and.
> > xor/add/sub/inc/dec can all compute either from either.
> > 
> > 
> > Also, please, I don't find the specifications clear.
> > At least the last time I studied them.
> > 
> > 
> > To me they should say, things like,
> > "returns the old value" 
> > or "returns the new value" 
> > 
> > 
> > or returns true if compare matched
> > or returns false if the compare matched
> > etc.
> > 
> > 
> > The mentions of "spurious failure" or whatnot didn't make sense either.
> > They should say, something like:
> > returns true if the compare matched
> > but sometimes even if the compare should have matched,
> > it won't, and false will be returned -- specify everything that happens when there is "failure".
> > 
> > 
> > Furthermore, if you look at what Microsoft compilers provide,
> > they provide a bunch of very simple very clear well documented functions,
> > that the compiler implements and inlines.
> > (at least if you ignore the qcuire/release stuff that confuses me...
> > 
> > 
> > You could specify in terms of them.
> > Really. A good idea.
> > 
> > 
> > ie: is our compare_exchange equivalent to InterlockedCompareExchange?
> > Or maybe parameter order different?
> > 
> > 
> > Of course, I understand, the types supported by the Microsoft
> > intrinsics have varied through time and slowly grown.
> > 8bit and 16bit might still be lacking but 32bit and 64bit are very
> > complete. 64bit atomic operations on 32bit x86 processors 
> > since Pentium or so can be synthesized with a loop over
> > InterlockedCompareExchange64.
> > 
> > 
> > Or in terms of the gcc intrinsics, probably similarly ok.
> > 
> > 
> > We should probably also nail down the implementation where
> > they aren't available.
> > 
> > 
> > And maybe put in safer defaults?
> > And quickly improve where we can, e.g. on all x86/AMD64 platforms.
> > 
> > 
> > Thanks,
> > - Jay
> > 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101019/d4c27182/attachment.html>

From jay.krell at cornell.edu  Tue Oct 19 12:39:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 19 Oct 2010 10:39:35 +0000
Subject: [M3devel] CM3, Windows and GCC
In-Reply-To: <AANLkTikK=HwxCsGtpHSe__KzNWOzjg54a0v8pwocU=WM@mail.gmail.com>
References: <AANLkTikK=HwxCsGtpHSe__KzNWOzjg54a0v8pwocU=WM@mail.gmail.com>
Message-ID: <COL101-W761547F7BEDE16B44EB9DE65B0@phx.gbl>


Yes, both such targets exist, I386_CYGWIN and I386_MINGW.
Nobody uses them. But they are there and have worked in the past.
Maybe time to make sure they work and keep them working (Hudson).
 
 
However you have somewhat confused apples/oranges.
Somewhat. We have our own builtin code generator. We only use
Microsoft tools for 1) a little bit of C 2) linker 3) C runtime.
You ought to be able to combine either backend with either runtime and either C compiler and either linker. Though I noticed the C runtimes are somewhat tied to the linkers.
 
Note that our builtin code generator generates pretty good code and does it fast.
 
MinGW is probably the way to go for "AMD64_NT" though.
  Or the proverbial C backend.
 
 
 - Jay


________________________________
> Date: Tue, 19 Oct 2010 01:08:07 +0800
> From: ttmrichter at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] CM3, Windows and GCC
>
> Is there any way through, say, MinGW (or, if absolutely necessary,
> Cygwin) to get the back-end for CM3 to target GCC on Windows instead of
> Microsoft's tool chain?
>
> -- 		 	   		  

From jay.krell at cornell.edu  Sat Oct 23 12:06:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Oct 2010 10:06:39 +0000
Subject: [M3devel] typenames vs. lexical scope vs. backend?
Message-ID: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>


Um.. the same name can be different types, in different scopes.


<*NOWARN*>PROCEDURE F1() =
TYPE T1 = INTEGER;
BEGIN
END F1;

<*NOWARN*>PROCEDURE F2() =
TYPE T1 = LONGINT;
BEGIN
END F2;

=>

(16) declare_procedure name:Main__F1 n_params:0 return_type:void lev:0 exported:false
(17) declare_typename my_id:0x195C2A74 name:T1

(18) declare_procedure name:Main__F2 n_params:0 return_type:void lev:0 exported:false
(19) declare_typename my_id:0x5562176 name:T1
(20) comment comment:F1
(21) set_source_line 6

(22) begin_procedure procedure:Main__F1
(23)???? set_source_line 7
(24)???? set_source_line 9
(25)???? exit_proc type:void
(26) end_procedure procedure:Main__F1

(27) comment comment:F2
(28) set_source_line 0xB(11)
(29) begin_procedure procedure:Main__F2
(30)???? set_source_line 0xC(12)
(31)???? set_source_line 0xE(14)
(32)???? exit_proc type:void
(33) end_procedure procedure:Main__F2


Is the backend to record the types within some scope, and then observe
the scopes coming back?


Or, then again, are typenames worth much to the backend?
Well, maybe.
They aren't needed for display the values of variables,
but they might be nice in expressions that include casts?

I'm thinking maybe the right thing is to ignore them in the backend.
??

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Sat Oct 23 20:04:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 23 Oct 2010 14:04:12 -0400
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
Message-ID: <E2C44EC5-93F6-4063-9224-316DDA91100E@cs.purdue.edu>

You could mangle the name to prefix the scope.

On 23 Oct 2010, at 06:06, Jay K wrote:

> 
> Um.. the same name can be different types, in different scopes.
> 
> 
> <*NOWARN*>PROCEDURE F1() =
> TYPE T1 = INTEGER;
> BEGIN
> END F1;
> 
> <*NOWARN*>PROCEDURE F2() =
> TYPE T1 = LONGINT;
> BEGIN
> END F2;
> 
> =>
> 
> (16) declare_procedure name:Main__F1 n_params:0 return_type:void lev:0 exported:false
> (17) declare_typename my_id:0x195C2A74 name:T1
> 
> (18) declare_procedure name:Main__F2 n_params:0 return_type:void lev:0 exported:false
> (19) declare_typename my_id:0x5562176 name:T1
> (20) comment comment:F1
> (21) set_source_line 6
> 
> (22) begin_procedure procedure:Main__F1
> (23)     set_source_line 7
> (24)     set_source_line 9
> (25)     exit_proc type:void
> (26) end_procedure procedure:Main__F1
> 
> (27) comment comment:F2
> (28) set_source_line 0xB(11)
> (29) begin_procedure procedure:Main__F2
> (30)     set_source_line 0xC(12)
> (31)     set_source_line 0xE(14)
> (32)     exit_proc type:void
> (33) end_procedure procedure:Main__F2
> 
> 
> Is the backend to record the types within some scope, and then observe
> the scopes coming back?
> 
> 
> Or, then again, are typenames worth much to the backend?
> Well, maybe.
> They aren't needed for display the values of variables,
> but they might be nice in expressions that include casts?
> 
> I'm thinking maybe the right thing is to ignore them in the backend.
> ??
> 
>  - Jay
> 		 	   		  



From dragisha at m3w.org  Sat Oct 23 21:44:16 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 23 Oct 2010 21:44:16 +0200
Subject: [M3devel] Runtime only package for Windows? With preselected
	modules?
Message-ID: <1287863056.19814.1585.camel@boromir.m3w.org>

I have a rpm spec file I am using and it by default makes cm3 package
and cm3-devel. Also, it does not contain all modula-3 packages, as most
of them are not used in typical cases.

Right now I am about to make install package for an application I am
delivering and runtime libs only package for Windows is what is on my
mind right now. Doable? Or I can skip it without problem with
build_standalone() ? How do I confirm it's statically linked? Under
linux I'll use ldd, but depends.exe (thanks Jay) does not show it to
me...Or it does?
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sun Oct 24 02:30:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Oct 2010 00:30:52 +0000
Subject: [M3devel] Runtime only package for Windows? With preselected
 modules?
In-Reply-To: <1287863056.19814.1585.camel@boromir.m3w.org>
References: <1287863056.19814.1585.camel@boromir.m3w.org>
Message-ID: <COL101-W408980139AB55C72705EC0E6400@phx.gbl>


With build_standalone you don't need to worry.
  As long as all your Modula-3 code is in one .dll per process.
  Er, I mean, as long as your Modula-3 is the .exe and no .dlls.


There is some need for shared state sometimes.
But if all the Modula-3 code is linked together, in the .exe, ok.


You know, imagine you have multiple Modula-3 .dlls loaded, standalone.
Which garbage collector? Maybe all of them, against their own allocations.
Maybe it is jus slow.


But what if you pass off Modula-3 traced references across .dll boundaries,
without sharing a garbage collector (m3core.dll). Then you'd have trouble.


This has nothing to do with Windows.
It is the general hazard of dynamic linking.


Sometimes dynamic linking is an opportunistic optimization.
  e.g. it doesn't matter if you share strlen or not. It is stateless. You can have
  any number of copies. More efficient to reduce, but not a big deal these days,
  with tons of disk space and address space and physical memory.


But sometimes a .dll is managing a shared resource.
e.g. some global variables.
Then having multiple copies of data/code can be confusing or very wrong.
e.g. consider something like setlocale().
Which code does it affect? Only code using the same C runtime.


Imagine I call fopen or malloc and give the result to another .dll that
calls fread or free. They have to share the same C runtime.
Or in a less likely case, the multiple C runtimes have to cooperate.


Same problem with CreateFile/ReadFile/CloseHandle, except
the system doesn't allow duplicate kernel32.dll or the underlying ntoskrnl.exe.


Think of "services".
For example there is "BITS" the background intelligent transfer service..
used by Windows Update. If you have more than one on a machine,
then the "background" and "intelligent" suffer.
But it'd still mostly work?


 - Jay

> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Sat, 23 Oct 2010 21:44:16 +0200
> Subject: [M3devel] Runtime only package for Windows? With preselected	modules?
> 
> I have a rpm spec file I am using and it by default makes cm3 package
> and cm3-devel. Also, it does not contain all modula-3 packages, as most
> of them are not used in typical cases.
> 
> Right now I am about to make install package for an application I am
> delivering and runtime libs only package for Windows is what is on my
> mind right now. Doable? Or I can skip it without problem with
> build_standalone() ? How do I confirm it's statically linked? Under
> linux I'll use ldd, but depends.exe (thanks Jay) does not show it to
> me...Or it does?
> -- 
> Dragi?a Duri? <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101024/56e18a25/attachment.html>

From rodney_bates at lcwb.coop  Sun Oct 24 02:50:04 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 23 Oct 2010 19:50:04 -0500
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
Message-ID: <4CC382BC.2080509@lcwb.coop>

No different from names of variables, formals, constants, or procedures.
I can't think why the backend would need them for code generation/optimization.

They do belong in debug info, however.  This happens now for type names in
stabs+ debug output, although the encoding is a mess, and quite different
from variables, etc.  m3gdb recognizes them in debug commands and applies
the usual scope rules in doing so.  They can be used, e.g. in LOOPHOLE.
In a few cases, m3gdb will give you a bit of structural description of
a type, but often just fully qualifies the type name and repeats that.
When there are multiple names for the same (structurally) type, it is you may
get a synonym type name.

I suspect there is some internal backend tracing that would also benefit from
type names, as with variables, etc.


Jay K wrote:
> Um.. the same name can be different types, in different scopes.
> 
> 
> <*NOWARN*>PROCEDURE F1() =
> TYPE T1 = INTEGER;
> BEGIN
> END F1;
> 
> <*NOWARN*>PROCEDURE F2() =
> TYPE T1 = LONGINT;
> BEGIN
> END F2;
> 
> =>
> 
> (16) declare_procedure name:Main__F1 n_params:0 return_type:void lev:0 exported:false
> (17) declare_typename my_id:0x195C2A74 name:T1
> 
> (18) declare_procedure name:Main__F2 n_params:0 return_type:void lev:0 exported:false
> (19) declare_typename my_id:0x5562176 name:T1
> (20) comment comment:F1
> (21) set_source_line 6
> 
> (22) begin_procedure procedure:Main__F1
> (23)     set_source_line 7
> (24)     set_source_line 9
> (25)     exit_proc type:void
> (26) end_procedure procedure:Main__F1
> 
> (27) comment comment:F2
> (28) set_source_line 0xB(11)
> (29) begin_procedure procedure:Main__F2
> (30)     set_source_line 0xC(12)
> (31)     set_source_line 0xE(14)
> (32)     exit_proc type:void
> (33) end_procedure procedure:Main__F2
> 
> 
> Is the backend to record the types within some scope, and then observe
> the scopes coming back?
> 
> 
> Or, then again, are typenames worth much to the backend?
> Well, maybe.
> They aren't needed for display the values of variables,
> but they might be nice in expressions that include casts?
> 
> I'm thinking maybe the right thing is to ignore them in the backend.
> ??
> 
>  - Jay
>  		 	   		  


From dragisha at m3w.org  Sun Oct 24 07:59:51 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 24 Oct 2010 07:59:51 +0200
Subject: [M3devel] Runtime only package for Windows? With preselected
 modules?
In-Reply-To: <COL101-W408980139AB55C72705EC0E6400@phx.gbl>
References: <1287863056.19814.1585.camel@boromir.m3w.org>
	<COL101-W408980139AB55C72705EC0E6400@phx.gbl>
Message-ID: <1287899991.19814.1680.camel@boromir.m3w.org>

Thank you for elaborate answer.

I did build_standalone() and so far so good... It only pulls system libs
as .dlls (and it is clearly visible by depends.exe) and C libs I
linked. 

Under Linux I changed link command so it linked part of these libs
statically too... I think we need more control there (previously
discussed import_static()). C people have that curse|control point where
they have to specify their link commands, but we probably need to
recognize patterns so we can abstract in m3makefiles and pass them on to
lower levels.

I do not agree on "big physical memory and everything..". No matter how
spacious modern computers are, bad design can chew all that in no time.
Same is true for processor speeds and we all recognize that, but we
easily forget about space being other leg of software/algorightm
efficiency.

On Sun, 2010-10-24 at 00:30 +0000, Jay K wrote:
> With build_standalone you don't need to worry.
>   As long as all your Modula-3 code is in one .dll per process.
>   Er, I mean, as long as your Modula-3 is the .exe and no .dlls.
> 
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Mon Oct 25 02:15:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 25 Oct 2010 00:15:46 +0000
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <4CC382BC.2080509@lcwb.coop>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>,
	<4CC382BC.2080509@lcwb.coop>
Message-ID: <COL101-W48B2A9FB06B01EA23B2E4DE6410@phx.gbl>


> No different from names of variables, formals, constants, or procedures.
> I can't think why the backend would need them for code generation/optimization.

 
For debugging.
 

> They do belong in debug info, however.
 
 
Exactly. Maybe.
Except, I'm thinking..maybe only for entering expressions with casts?
Maybe not for viewing any values?
 
I think the way the compiler is currently structured, it is a lot of work to get this right,
and not with much gain.
The gain would be that typenames in expressions with casts would be 1) evaluated
relative to context 2) easier...typenames should probably be lengthened
in order to have a context-independent name. The lexical scopes
that introduce type names, in order of decreasing frequency would be roughly:
  module
  toplevel function in a module
  block or nested function 
 
We could qualify typenames with Module or Module.Function or Module.Function.NestedFunction.
There's no obvious good name for blocks (WITH, FOR, etc.), but maybe numbers 0, 1, 2, etc.
 
 
I think the frontend and frontend/backend interface need work.
In this case there's not much to gain.
I'll cover something else in a separate mail.
 
 
 - Jay
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101025/675b348f/attachment.html>

From jay.krell at cornell.edu  Mon Oct 25 02:21:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 25 Oct 2010 00:21:43 +0000
Subject: [M3devel] backend and field/array references
Message-ID: <COL101-W293BBD4A33BC418CA80B56E6410@phx.gbl>


The frontend/backend interface should have notions of record field accesses and array indexing.
I'm not sure exactly what they should look like but it shouldn't be difficult to figure out,
at least some simple approaches that scale well enough, even if not ideally.
 
 
For example, every field in a record should either have an id 0, 1, 2, etc. allocated within the record.
OR every field in a record should have an id a la hashes/fingerprints, that could be
sorted/searched globally, even if that isn't as efficient as it could be.
 
 
What I'll probably get working before any of this is in m3_load/store, do a linear search within
the fields of the variable for a field whose offset/size matches.
But linearch search is almost never a good solution.
It could be implemented as binary search with the current interface.
 
 
Due to the danger of layout mismatch, I'm plenty willing for field/array accesses to include
with them the offset the frontend believes them to be at, and it'd be a checked internal error
in the backend if the frontend and backend offset/size disagree.
This would also aid backends that don't have such a high level internal representation (i.e.: NT386).
 
 
I have something prototyped here and it somewhat works.
I have a check that all accesses can be have a field deduced for them.
The first place that fails is for open arrays, for obvious reasons, which I'll fix.
I'll see how it goes from there.
 
 
Ultimately I'm still keen on a C-generating frontend, which does not moot this.
  It would allow for more sensible C to be generated.
 
 
 
 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101025/cf3720ff/attachment.html>

From rodney_bates at lcwb.coop  Mon Oct 25 19:17:48 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 25 Oct 2010 12:17:48 -0500
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <COL101-W48B2A9FB06B01EA23B2E4DE6410@phx.gbl>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>,
	<4CC382BC.2080509@lcwb.coop>
	<COL101-W48B2A9FB06B01EA23B2E4DE6410@phx.gbl>
Message-ID: <4CC5BBBC.5070206@lcwb.coop>



Jay K wrote:
>  > No different from names of variables, formals, constants, or procedures.
>  > I can't think why the backend would need them for code 
> generation/optimization.
> 
>  
> For debugging.
>  
> 
>  > They do belong in debug info, however.
>  
>  
> Exactly. Maybe.
> Except, I'm thinking..maybe only for entering expressions with casts?
> Maybe not for viewing any values?
>  
> I think the way the compiler is currently structured, it is a lot of 
> work to get this right,
> and not with much gain.
> The gain would be that typenames in expressions with casts would be 1) 
> evaluated
> relative to context 2) easier...typenames should probably be lengthened
> in order to have a context-independent name. The lexical scopes
> that introduce type names, in order of decreasing frequency would be 
> roughly:
>   module
>   toplevel function in a module
>   block or nested function
>  
> We could qualify typenames with Module or Module.Function or 
> Module.Function.NestedFunction.
> There's no obvious good name for blocks (WITH, FOR, etc.), but maybe 
> numbers 0, 1, 2, etc.

Whether it's either obvious or good remains subject to debate, but there is already
a system for this, used by m3gdb.  See doc/help/m3gdb/m3gdb-onepage.html, section
"linespecs that are qualified references".  As for the subterfuge behind the scenes,
wherein the compiler and m3gdb communicate info through stabs+, it's a mess.

>  
>  
> I think the frontend and frontend/backend interface need work.
> In this case there's not much to gain.
> I'll cover something else in a separate mail.
>  
>  
>  - Jay
>  


From jay.krell at cornell.edu  Wed Oct 27 09:24:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 07:24:09 +0000
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
Message-ID: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>


My Linux/x86 and OpenBSD/x86 nodes are back from a few days ago.
?? err..need to check if they are working..

I'm experimenting with using Amazon Web Services though.
Reserved micro instances are about $7/month if I computed correctly and the first is free for the first year.
Unclear how easy OpenBSD/NetBSD etc. are to run there though.
? Or maybe just slow (i.e. not paravirtualized)
I'm seeing stuff in German lately in Hudson, but I understand very little German.
It looks like cvs/gcc is moving?
?Or all of cm3/cvs?


e.g.: http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console

http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console


(implied: others here should probably setup some instances, at least if non-Linux proves easy enough;
I'll try OpenBSD probably first)

?- Jay
 		 	   		  

From wagner at elegosoft.com  Wed Oct 27 10:04:09 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 27 Oct 2010 10:04:09 +0200
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
In-Reply-To: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>
References: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>
Message-ID: <20101027100409.3807ovva8gs80os4@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> My Linux/x86 and OpenBSD/x86 nodes are back from a few days ago.
> ?? err..need to check if they are working..
>
> I'm experimenting with using Amazon Web Services though.
> Reserved micro instances are about $7/month if I computed correctly   
> and the first is free for the first year.
> Unclear how easy OpenBSD/NetBSD etc. are to run there though.
> ? Or maybe just slow (i.e. not paravirtualized)

I haven't tried that yet; but if you want to set up a test node there,
that would be welcome.

> I'm seeing stuff in German lately in Hudson, but I understand very   
> little German.

I've seen that, too, now and then. It's not intended, and likely to be
a configuration issue or a global OS setting that somehow gets
heeded now. Perhaps Mike can shed some light on this if he can spare
some minutes...

> It looks like cvs/gcc is moving?
> ?Or all of cm3/cvs?

I'm not sure what you are hinting at with that.
I don't know of any move, nor have I heard anything new of the git/hg
front work.

> e.g.:   
> http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console
>
> http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console

These are examples of German texts I assume...
We'll try to fix that, but it's low priority.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Wed Oct 27 10:22:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 08:22:55 +0000
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
In-Reply-To: <20101027100409.3807ovva8gs80os4@mail.elegosoft.com>
References: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>,
	<20101027100409.3807ovva8gs80os4@mail.elegosoft.com>
Message-ID: <COL101-W7401FFDF127168A912361E6430@phx.gbl>


> > I'm experimenting with using Amazon Web Services though.
> I haven't tried that yet; but if you want to set up a test node there,
> that would be welcome.


It's gotten further. Below.


> > It looks like cvs/gcc is moving?
> >  Or all of cm3/cvs?
>
> I'm not sure what you are hinting at with that.


Look at the CVS roots in hudson.
I'm seeing cm3cvs.acme-works.com.
I never saw that before tonight.


> > e.g.:
> > http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console
> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console
>
> These are examples of German texts I assume...

That too..
But: These are examples running in Amazon Web Services actually.
"jaws1" -- Jay Amazon Web Services 1


question then: what is the thinking around having multiple nodes of same "type"?
? You know..I setup a "test" node..can that coexist with a "real" node? Or only in that
? I fiddle with the jobs to be on one, run them, and then put it back if it didsn't work?
Shedule the jobs on all of them?
If they all work, purely redundant.
If some nodes down, the redundancy useful?
I could see powering off the AWS nodes for long periods to save money.
? esp. if I get NetBSD and OpenBSD running there.
? heck, it might be possible to run Darwin there. Might.
Just change the "tags" that "bind" jobs to machines, to say like linux-i386 instead of machine names xlinux, jaws1, etc.??


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed Oct 27 10:46:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 08:46:21 +0000
Subject: [M3devel] small problems bring up new node
Message-ID: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>


Olaf, bringing up new nodes I think finds small problems in the automation.


new node: jaws1 which is Linux/x86
? (Rename it if you don't like it.)

? 
initial install worked in one attempt, good:
http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/


building cm3cg worked in one attempt, good:
http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/


but building the rest failed, for lack of "last ok" build:
http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull


I'm sure if I just copy stuff around it'll work.
Unless we need to start with a newer release,
which is a different matter if so.


This node was cloned from xlinux and I just changed the node
name and node to ssh to.


(The great thing about a C backend is all this testing
across every architecture would all but disappear..)


?- Jay 		 	   		  

From wagner at elegosoft.com  Wed Oct 27 11:02:19 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 27 Oct 2010 11:02:19 +0200
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
In-Reply-To: <COL101-W7401FFDF127168A912361E6430@phx.gbl>
References: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>,
	<20101027100409.3807ovva8gs80os4@mail.elegosoft.com>
	<COL101-W7401FFDF127168A912361E6430@phx.gbl>
Message-ID: <20101027110219.q48envgsgwwg0k44@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>> > I'm experimenting with using Amazon Web Services though.
>> I haven't tried that yet; but if you want to set up a test node there,
>> that would be welcome.
>
> It's gotten further. Below.
Ah.

>> > It looks like cvs/gcc is moving?
>> >  Or all of cm3/cvs?
>>
>> I'm not sure what you are hinting at with that.
>
> Look at the CVS roots in hudson.
> I'm seeing cm3cvs.acme-works.com.
> I never saw that before tonight.

Oops, I forgot about that. That's a mirror on a virtual machine
Mike has set up; I thought I posted that to the list. Only a few
jobs use(d) it until now though. It's only a temporary solution,
though these always tend to become long-living :-)

>> > e.g.:
>> >   
>> http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console
>> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console
>>
>> These are examples of German texts I assume...
>
> That too..
> But: These are examples running in Amazon Web Services actually.
> "jaws1" -- Jay Amazon Web Services 1
>
> question then: what is the thinking around having multiple nodes of   
> same "type"?

You mean for one target platform, I assume?

> ? You know..I setup a "test" node..can that coexist with a "real"   
> node? Or only in that
> ? I fiddle with the jobs to be on one, run them, and then put it   
> back if it didsn't work?

Feel free to add test nodes as you need (not necessarily run continuous
integration on them because of the load that generates).

> Shedule the jobs on all of them?
We shouldn't actually run the same builds and tests on multiple nodes
for a longer period of time.

> If they all work, purely redundant.
> If some nodes down, the redundancy useful?

Yes, it would be great to have an automated switchover in this case.
Except for the job dependeny from build on m3cc there should be no
problem in defining a group of equivalent nodes in Hudson (that's the
provided concept).

> I could see powering off the AWS nodes for long periods to save money.
> ? esp. if I get NetBSD and OpenBSD running there.
> ? heck, it might be possible to run Darwin there. Might.
> Just change the "tags" that "bind" jobs to machines, to say like   
> linux-i386 instead of machine names xlinux, jaws1, etc.??

Yes, that's the mechanism to define groups of equivalent slave
machines. Add a unique tag to all the build nodes that may run your job
and use that in the job definition.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Wed Oct 27 11:19:49 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 27 Oct 2010 11:19:49 +0200
Subject: [M3devel] small problems bring up new node
In-Reply-To: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>
References: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>
Message-ID: <20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Olaf, bringing up new nodes I think finds small problems in the automation.
>
> new node: jaws1 which is Linux/x86
> ? (Rename it if you don't like it.)
> ?
> initial install worked in one attempt, good:
> http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/
>
> building cm3cg worked in one attempt, good:
> http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/
>
> but building the rest failed, for lack of "last ok" build:
> http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull

That hasn't been realluy automated in a generic fashion yet.
I always had to perform several steps more or less manually due to
different environments etc. If you can write a general boot or init
job that will be great.

The build and test jobs all expect valid cm3 package pool setups
in current and lastok. That at least should be easy to automate.

> I'm sure if I just copy stuff around it'll work.
> Unless we need to start with a newer release,
> which is a different matter if so.
>
> This node was cloned from xlinux and I just changed the node
> name and node to ssh to.

There are different variants of init jobs for different platforms.
Maybe you just were unlucky to pick a rather old one :-/

> (The great thing about a C backend is all this testing
> across every architecture would all but disappear..)

No, it wouldn't. We could neither be sure that the generated C code
compiles with a native compiler (unless we require the same version
of gcc everywhere) nor that it would perform in the same way on all
platforms. That doesn't mean that a C backend wouldn't be a great
extension, of course.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Wed Oct 27 11:28:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 09:28:14 +0000
Subject: [M3devel] small problems bring up new node
In-Reply-To: <20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>
References: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>,
	<20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>
Message-ID: <COL101-W53C69CA2CF01060D50A5EBE6430@phx.gbl>


Hm. I think most of the code is outside of Hudson by now, but I'll poke around.


We would generate highly portable C/C++.
We wouldn't depend on gcc. gcc just isn't, in my experience, so much better/different
than any other C/C++ compiler -- partly because I mostly use Microsoft Visual C++ and
that compiler has fairly few extensions. Perhaps if I used gcc more I'd be lulled into using
its many unique extensions.
#ifdef linux would generally suffice for Linux on all processors.
? No need for the ppc/sparc/etc. machines.
#ifdef freebsd ditto.
? No need for the ppc/sparc/etc. machines.
As well, autoconf might subsume some of that.

We might still try to have some 32bit and 64bit machines, some sparc, mips, etc., but
? no need for the full cross product.


endian and wordsize would be separate factors
We may or may not need to know them statically.
i.e. we would either typedef integer like in m3core.h, or use autoconf.


I think if m3cg had a notion of a field reference, the front end would no longer
care about endian. I think it only uses it to layout bitfields within bytes/integers.
Heck -- given that we have no bitfields used between C and Modula-3, I think this
dependency can be removed already, just do the layout arbitrarily!


?- Jay


----------------------------------------
> Date: Wed, 27 Oct 2010 11:19:49 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] small problems bring up new node
>
> Quoting Jay K :
>
> > Olaf, bringing up new nodes I think finds small problems in the automation.
> >
> > new node: jaws1 which is Linux/x86
> >   (Rename it if you don't like it.)
> >
> > initial install worked in one attempt, good:
> > http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/
> >
> > building cm3cg worked in one attempt, good:
> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/
> >
> > but building the rest failed, for lack of "last ok" build:
> > http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull
>
> That hasn't been realluy automated in a generic fashion yet.
> I always had to perform several steps more or less manually due to
> different environments etc. If you can write a general boot or init
> job that will be great.
>
> The build and test jobs all expect valid cm3 package pool setups
> in current and lastok. That at least should be easy to automate.
>
> > I'm sure if I just copy stuff around it'll work.
> > Unless we need to start with a newer release,
> > which is a different matter if so.
> >
> > This node was cloned from xlinux and I just changed the node
> > name and node to ssh to.
>
> There are different variants of init jobs for different platforms.
> Maybe you just were unlucky to pick a rather old one :-/
>
> > (The great thing about a C backend is all this testing
> > across every architecture would all but disappear..)
>
> No, it wouldn't. We could neither be sure that the generated C code
> compiles with a native compiler (unless we require the same version
> of gcc everywhere) nor that it would perform in the same way on all
> platforms. That doesn't mean that a C backend wouldn't be a great
> extension, of course.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From dragisha at m3w.org  Wed Oct 27 23:41:19 2010
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 27 Oct 2010 23:41:19 +0200
Subject: [M3devel] small problems bring up new node (autoconf????)
In-Reply-To: <COL101-W53C69CA2CF01060D50A5EBE6430@phx.gbl>
References: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>,
	<20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>
	<COL101-W53C69CA2CF01060D50A5EBE6430@phx.gbl>
Message-ID: <A485C743-B052-4BB1-9E44-EF13F47B871D@m3w.org>

Autoconf will be used in future cm3????

On Oct 27, 2010, at 11:28 AM, Jay K wrote:

> As well, autoconf might subsume some of that.



From wagner at elegosoft.com  Fri Oct 29 14:11:34 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 29 Oct 2010 14:11:34 +0200
Subject: [M3devel] recent cm3cg regression
Message-ID: <20101029141134.7gx4toby80w4k0gs@mail.elegosoft.com>

recent m3cc changes lead to lots of compilation errors, e.g.

http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-AMD64_FREEBSD/133/console

please fix

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Oct 29 21:16:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 29 Oct 2010 19:16:21 +0000
Subject: [M3devel] recent cm3cg regression
In-Reply-To: <20101029141134.7gx4toby80w4k0gs@mail.elegosoft.com>
References: <20101029141134.7gx4toby80w4k0gs@mail.elegosoft.com>
Message-ID: <COL101-W20AC67BB0B46D76B4C3BA4E6450@phx.gbl>


oops sorry I forgot to commit m3gty45.h.

?- Jay



----------------------------------------
> Date: Fri, 29 Oct 2010 14:11:34 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] recent cm3cg regression
>
> recent m3cc changes lead to lots of compilation errors, e.g.
>
> http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-AMD64_FREEBSD/133/console
>
> please fix
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From jay.krell at cornell.edu  Sun Oct 31 05:43:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 04:43:59 +0000
Subject: [M3devel] "looping to get all types declared first"
Message-ID: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>


There is this "replay" thing I put in the backend.
It isn't quite right.
 
 
I would like to have multiple passes, where if
all the types haven't been declared yet, non-type-declaration
operations do nothing.
 
There are approximately three approaches.
 
 1) the frontend front-loads all type declarations
so as soon as non-type declaration seen, that is the end,
ok to loop; I don't know if this is true.
 
 
 2) in each operand implementation, check if all the types
  have been declared yet and if not and if the operation
  isn't a declaration, immediately return
  This isn't entirely true. Some things like begin unit/procedure/block
  need to do anything, to track lexical location for building
  prefixes on type names, or somesuch.
 
 Actually, I think all the type data structures might need
to be in a linked list going from inner scope to outer scope
and searches have to search them in order and take the first hit. ?
 
 
 3) or, similarly, but the question is, do we loop
  over the serialized form, or do we first deserialize
  into an in-memory form, and then loop over that?
 
 
Those are my main questions:
   a) does the front end front-load declarations? I can trace a bit in cm3cg and guess.
   b) if not, do people prefer multiple passes over the serialized form or
   first deserialize into an in-memory form, and then loop over that
   c) change frontend to front-load declarations
 
 
My preference is b.
It is isn't the most efficient, but the efficiency should be plenty adequate.
 
 
I understand typeids are hashes, so scope is sort of irrelevant.
But typenames specifically are scoped.
 
 
 - Jay 		 	   		  

From jay.krell at cornell.edu  Sun Oct 31 08:20:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 07:20:37 +0000
Subject: [M3devel] va/loophole/integers
Message-ID: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>


When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.


I think this is wrong in multiple ways.


For 64bit targets, nothing should be done.
Backend can check that it is given equal types.
This might already be done.


A range check should be done.
Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.
Code that wants to ignore this can..well..it takes a bit if code I guess, but still.

Similarly for LONGCARD to CARDINAL

And then, still, I don't think loophole is appropriate.

Perhaps loophole in backend isn't meant to match up to loophole in the language?
I guess, maybe, but this seems...not intuitive.

In particular I tried making loophole use VIEW_CONVERT and I was look at the
affect here:

libm3/.../FilePosix.m3

PROCEDURE RegularFileSeek(
??? h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
? : INTEGER RAISES {OSError.E} =
? BEGIN
??? WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
????? IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
????? RETURN VAL(result, INTEGER)
??? END
? END RegularFileSeek;



(1034) call_direct procedure:Unix__lseek type:int64
(1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
(1036) store var:noname offset:0 src_t:int64 dst_t:int64
(1037) begin_block
(1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
(1039) load var:noname offset:0 src_t:int64 dst_t:int64
(1040) store var:result offset:0 src_t:int64 dst_t:int64
(1041) set_source_line 0x96(150)
(1042) load_integer type:int32 0
(1043) loophole type1:int32 type2:int64



and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.


Probably the backend should check that loophole is using two equal sized types, and then use view convert.
Though for now at least it has to deal with these integer conversions.


?- Jay

 		 	   		  

From hosking at cs.purdue.edu  Sun Oct 31 17:48:58 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 31 Oct 2010 12:48:58 -0400
Subject: [M3devel] "looping to get all types declared first"
In-Reply-To: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>
References: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>
Message-ID: <98707534-E63B-414E-BD43-508BB9A2C3D0@cs.purdue.edu>

I don't understand the purpose of all this.  Can't you just maintain one global table mapping type id to type?

On Oct 31, 2010, at 12:43 AM, Jay K wrote:

> 
> There is this "replay" thing I put in the backend.
> It isn't quite right.
> 
> 
> I would like to have multiple passes, where if
> all the types haven't been declared yet, non-type-declaration
> operations do nothing.
> 
> There are approximately three approaches.
> 
> 1) the frontend front-loads all type declarations
> so as soon as non-type declaration seen, that is the end,
> ok to loop; I don't know if this is true.
> 
> 
> 2) in each operand implementation, check if all the types
>  have been declared yet and if not and if the operation
>  isn't a declaration, immediately return
>  This isn't entirely true. Some things like begin unit/procedure/block
>  need to do anything, to track lexical location for building
>  prefixes on type names, or somesuch.
> 
> Actually, I think all the type data structures might need
> to be in a linked list going from inner scope to outer scope
> and searches have to search them in order and take the first hit. ?
> 
> 
> 3) or, similarly, but the question is, do we loop
>  over the serialized form, or do we first deserialize
>  into an in-memory form, and then loop over that?
> 
> 
> Those are my main questions:
>   a) does the front end front-load declarations? I can trace a bit in cm3cg and guess.
>   b) if not, do people prefer multiple passes over the serialized form or
>   first deserialize into an in-memory form, and then loop over that
>   c) change frontend to front-load declarations
> 
> 
> My preference is b.
> It is isn't the most efficient, but the efficiency should be plenty adequate.
> 
> 
> I understand typeids are hashes, so scope is sort of irrelevant.
> But typenames specifically are scoped.
> 
> 
> - Jay 		 	   		  



From hosking at cs.purdue.edu  Sun Oct 31 18:51:14 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 31 Oct 2010 13:51:14 -0400
Subject: [M3devel] va/loophole/integers
In-Reply-To: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>
References: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>
Message-ID: <3D7DC9AE-0089-48AE-BA7D-6DB07BDD1F85@cs.purdue.edu>

On Oct 31, 2010, at 3:20 AM, Jay K wrote:

> When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.

Possibly.  LOOPHOLE in the language expects values with equal BITSIZE.  I used it originally because LOOPHOLE as implemented seemed to do the right thing.  Probably we should use widen/chop (as defined in M3CG_Ops.i3).

> I think this is wrong in multiple ways.
> 
> 
> For 64bit targets, nothing should be done.
> Backend can check that it is given equal types.
> This might already be done.

If they are same BITSIZE then loophole is appropriate, no?

> A range check should be done.

We have a range check in VAL:

      Expr.GetBounds (ce.args[0], minu, maxu);
      EVAL Type.GetBounds (t, mint, maxt);
      IF TInt.LT (minu, mint) THEN
        (* we need a lower bound check *)
        IF TInt.LT (maxt, maxu) THEN
          (* we also need an upper bound check *)
          ce.args[0] := CheckExpr.New (ce.args[0], mint, maxt,
                                          CG.RuntimeError.ValueOutOfRange);
          Expr.TypeCheck (ce.args[0], cs);
        ELSE
          ce.args[0] := CheckExpr.NewLower (ce.args[0], mint,
                                          CG.RuntimeError.ValueOutOfRange);
          Expr.TypeCheck (ce.args[0], cs);
        END;
      ELSIF TInt.LT (maxt, maxu) THEN
        (* we need an upper bound check *)
        ce.args[0] := CheckExpr.NewUpper (ce.args[0], maxt,
                                          CG.RuntimeError.ValueOutOfRange);
        Expr.TypeCheck (ce.args[0], cs);
      END;


> Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.

This *will* raise an exception if it doesn't fit.

> Code that wants to ignore this can..well..it takes a bit if code I guess, but still.
> Similarly for LONGCARD to CARDINAL

Should be the same.

> And then, still, I don't think loophole is appropriate.
> 
> Perhaps loophole in backend isn't meant to match up to loophole in the language?
> I guess, maybe, but this seems...not intuitive.

Perhaps we should use widen/chop?

> In particular I tried making loophole use VIEW_CONVERT and I was look at the
> affect here:
> 
> libm3/.../FilePosix.m3
> 
> PROCEDURE RegularFileSeek(
>     h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
>   : INTEGER RAISES {OSError.E} =
>   BEGIN
>     WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
>       IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
>       RETURN VAL(result, INTEGER)
>     END
>   END RegularFileSeek;
> 
> 
> 
> (1034) call_direct procedure:Unix__lseek type:int64
> (1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
> (1036) store var:noname offset:0 src_t:int64 dst_t:int64
> (1037) begin_block
> (1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
> (1039) load var:noname offset:0 src_t:int64 dst_t:int64
> (1040) store var:result offset:0 src_t:int64 dst_t:int64
> (1041) set_source_line 0x96(150)
> (1042) load_integer type:int32 0
> (1043) loophole type1:int32 type2:int64
> 
> 
> 
> and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.
> 
> 
> Probably the backend should check that loophole is using two equal sized types, and then use view convert.
> Though for now at least it has to deal with these integer conversions.
> 
> 
>  - Jay
> 
> 		 	   		  



From jay.krell at cornell.edu  Sun Oct 31 21:50:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 20:50:14 +0000
Subject: [M3devel] va/loophole/integers
In-Reply-To: <3D7DC9AE-0089-48AE-BA7D-6DB07BDD1F85@cs.purdue.edu>
References: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>,
	<3D7DC9AE-0089-48AE-BA7D-6DB07BDD1F85@cs.purdue.edu>
Message-ID: <COL101-W1960B31CCD5A3F3A1CF8EE6470@phx.gbl>


I admit I didn't read all the code or try a test -- so the range check could be there already, yes.

?> LOOPHOLE in the language expects values with equal BITSIZE

Ok. So the assert I added is redundant, but that's ok, asserts usually are.

> Perhaps we should use widen/chop?

Sounds promising.

I admit I'm just not sure. The current code doesn't seem terrible.
General pattern: Lots of things are surprising (not intuitive) when first discovered.
But that doesn't make them wrong or unreasonable.

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sun, 31 Oct 2010 13:51:14 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] va/loophole/integers
>
> On Oct 31, 2010, at 3:20 AM, Jay K wrote:
>
> > When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.
>
> Possibly. LOOPHOLE in the language expects values with equal BITSIZE. I used it originally because LOOPHOLE as implemented seemed to do the right thing. Probably we should use widen/chop (as defined in M3CG_Ops.i3).
>
> > I think this is wrong in multiple ways.
> >
> >
> > For 64bit targets, nothing should be done.
> > Backend can check that it is given equal types.
> > This might already be done.
>
> If they are same BITSIZE then loophole is appropriate, no?
>
> > A range check should be done.
>
> We have a range check in VAL:
>
> Expr.GetBounds (ce.args[0], minu, maxu);
> EVAL Type.GetBounds (t, mint, maxt);
> IF TInt.LT (minu, mint) THEN
> (* we need a lower bound check *)
> IF TInt.LT (maxt, maxu) THEN
> (* we also need an upper bound check *)
> ce.args[0] := CheckExpr.New (ce.args[0], mint, maxt,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> ELSE
> ce.args[0] := CheckExpr.NewLower (ce.args[0], mint,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> END;
> ELSIF TInt.LT (maxt, maxu) THEN
> (* we need an upper bound check *)
> ce.args[0] := CheckExpr.NewUpper (ce.args[0], maxt,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> END;
>
>
> > Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.
>
> This *will* raise an exception if it doesn't fit.
>
> > Code that wants to ignore this can..well..it takes a bit if code I guess, but still.
> > Similarly for LONGCARD to CARDINAL
>
> Should be the same.
>
> > And then, still, I don't think loophole is appropriate.
> >
> > Perhaps loophole in backend isn't meant to match up to loophole in the language?
> > I guess, maybe, but this seems...not intuitive.
>
> Perhaps we should use widen/chop?
>
> > In particular I tried making loophole use VIEW_CONVERT and I was look at the
> > affect here:
> >
> > libm3/.../FilePosix.m3
> >
> > PROCEDURE RegularFileSeek(
> > h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
> > : INTEGER RAISES {OSError.E} =
> > BEGIN
> > WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
> > IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
> > RETURN VAL(result, INTEGER)
> > END
> > END RegularFileSeek;
> >
> >
> >
> > (1034) call_direct procedure:Unix__lseek type:int64
> > (1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
> > (1036) store var:noname offset:0 src_t:int64 dst_t:int64
> > (1037) begin_block
> > (1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
> > (1039) load var:noname offset:0 src_t:int64 dst_t:int64
> > (1040) store var:result offset:0 src_t:int64 dst_t:int64
> > (1041) set_source_line 0x96(150)
> > (1042) load_integer type:int32 0
> > (1043) loophole type1:int32 type2:int64
> >
> >
> >
> > and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.
> >
> >
> > Probably the backend should check that loophole is using two equal sized types, and then use view convert.
> > Though for now at least it has to deal with these integer conversions.
> >
> >
> > - Jay
> >
> >
>
 		 	   		  

From jay.krell at cornell.edu  Sun Oct 31 21:54:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 20:54:34 +0000
Subject: [M3devel] "looping to get all types declared first"
In-Reply-To: <98707534-E63B-414E-BD43-508BB9A2C3D0@cs.purdue.edu>
References: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>,
	<98707534-E63B-414E-BD43-508BB9A2C3D0@cs.purdue.edu>
Message-ID: <COL101-W13EDB0642C9A0A6E24EE88E6470@phx.gbl>


> I don't understand the purpose of all this. Can't you just maintain one global table mapping type id to type?

The general problem is that types are used before they are declared.
Another problem is my ignorance of what is possible.

For example, is it possible to just no type on everything at first, just a struct lang_type with typeid,
and then walk the gcc trees repeatedly replacing those as possible?

Would that require, perhaps, setting unit_at_a_time = true, which is an optimization, but ok?

Or do all the types need to be correct upon initial tree construction?

If they have to be correct up front, it takes multiple passes through the type declarations due to
circularities or out-of-orders.

I have something in place for multiple passes, but it doesn't avoid building statements (non-declarations)
in the earlier passes.

Typenames are not amenable to one global table, but I'm not sure they matter at all.
I'm thinking the backend can basically ignore them entirely -- or at least not do anything new with them
in this effort to make the trees correctly typed.


?- Jay
 		 	   		  

From dragisha at m3w.org  Fri Oct  1 00:40:17 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 01 Oct 2010 00:40:17 +0200
Subject: [M3devel] Windows... cm3... linking...
In-Reply-To: <1285879260.3196.2.camel@boromir.m3w.org>
References: <1285879260.3196.2.camel@boromir.m3w.org>
Message-ID: <1285886417.3196.5.camel@boromir.m3w.org>

Got through this... phew... :)

As I am using Shining Light OpenSSL-Win32 port, I jad to get through
with options... Pretty obvious except part where if \\ used
in /LIBPATH:, openssl lib compiles and ships but client apps does not -
there is no \ in sight.

Solution is - even when making m3makefile for Win32 - use / as path
separator.

On Thu, 2010-09-30 at 22:41 +0200, Dragi?a Duri? wrote:
> Anybody doing this? What is m3makefile "magic" for it?

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  1 02:23:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 00:23:50 +0000
Subject: [M3devel] Windows... cm3... linking...
In-Reply-To: <1285886417.3196.5.camel@boromir.m3w.org>
References: <1285879260.3196.2.camel@boromir.m3w.org>,
	<1285886417.3196.5.camel@boromir.m3w.org>
Message-ID: <COL101-W4764E31E9BC2F7341C98D1E6690@phx.gbl>


Your original question was very unclear.
 
 - Jay


----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Fri, 1 Oct 2010 00:40:17 +0200
> Subject: Re: [M3devel] Windows... cm3... linking...
>
> Got through this... phew... :)
>
> As I am using Shining Light OpenSSL-Win32 port, I jad to get through
> with options... Pretty obvious except part where if \\ used
> in /LIBPATH:, openssl lib compiles and ships but client apps does not -
> there is no \ in sight.
>
> Solution is - even when making m3makefile for Win32 - use / as path
> separator.
>
> On Thu, 2010-09-30 at 22:41 +0200, Dragi?a Duri? wrote:
> > Anybody doing this? What is m3makefile "magic" for it?
>
> --
> Dragi?a Duri? 
> 		 	   		  

From jay.krell at cornell.edu  Fri Oct  1 12:17:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 10:17:23 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
Message-ID: <COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>


Huh? You mean hack, cross once, unhack?
I want to cross build as a regular occurence. The entire system.
I already do actually. But currently only enough to get cm3.
The problems occur if you try to build the entire system.
? Ok, right, I left one of the hacks in actually.
? Like TEXTs have a 2GB size limit or such.


"Regular" cross builds are normal in other environments these days.


?- Jay

----------------------------------------
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
> From: hosking at cs.purdue.edu
> Date: Thu, 30 Sep 2010 09:42:59 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> Whenever you cross build you should do a subsequent native bootstrap to eliminate those.
>
> On 30 Sep 2010, at 07:14, Jay K wrote:
>
> >
> > So..we can't fully cross build a 64bit target from a 32bit host because some code
> > wants to declare arrays that fill memory, like so that indexing them never fails
> > an overflow check:
> >
> >
> > TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example
> >
> >
> > I'm faced with a few choices:
> > - do nothing
> > - have the front end pin the sizes to its maximum
> > Leading to such code to fail if it actually operates on data larger than 2GB
> > - use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less
> > - use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long",
> > (roughly: "long" suffices instead on most 64bit systems)
> > - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c
> >
> >
> > Extremely similarly btw:
> >
> >
> > TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example
> > TYPE T2 = RECORD a,b,c:T1; END;
> >
> >
> > which is just to say, it isn't just about total array sizes, but also field offsets.
> >
> >
> > (I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...)
> >
> >
> >
> > I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code.
> > e.g. m3front/src/types/Type.i3/Info, and then all its users.
> >
> > Should these types use a different and unsafe form?
> > Do we have a convenient unsafe form?
> >
> > - Jay
> >
>
 		 	   		  

From jay.krell at cornell.edu  Fri Oct  1 12:19:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 10:19:35 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <1285845869.2729.7.camel@boromir.m3w.org>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<1285845869.2729.7.camel@boromir.m3w.org>
Message-ID: <COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>


Really? What technique was employed?
The current system doesn't work as I want. As most other compilers now do.
You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
Right. In the past gcc didn't have such good cross building capabilities.
So that might have helped.
Now it does. Now cm3cg has no problem crossing arbitrarily.
But the cm3 frontend does.
A 32bit cm3 frontend can't handle sizes larger than 4GB.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 30 Sep 2010 13:24:29 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>
> I went this route a decade or so ago... When I was porting pm3 to
> Linux/ALPHA... John Polstra employed same technique later for ezm3...
>
> Standard bootstrap process splits build process at assembly level. For
> Windows it is split at object code level.
>
> What I did was to split it ad GCC "IR" level. that way, 32->64 bit
> crosscompiler was never required.
>
> On Thu, 2010-09-30 at 11:14 +0000, Jay K wrote:
> > So..we can't fully cross build a 64bit target from a 32bit host
> > because some code
> > wants to declare arrays that fill memory, like so that indexing them
> > never fails
> > an overflow check:
> >
> >
> >
> --
> Dragi?a Duri? 
>
 		 	   		  

From wagner at elegosoft.com  Fri Oct  1 12:37:23 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Oct 2010 12:37:23 +0200
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<1285845869.2729.7.camel@boromir.m3w.org>
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>
Message-ID: <20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>
> Really? What technique was employed?
> The current system doesn't work as I want. As most other compilers now do.
> You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
> Right. In the past gcc didn't have such good cross building capabilities.
> So that might have helped.
> Now it does. Now cm3cg has no problem crossing arbitrarily.
> But the cm3 frontend does.
> A 32bit cm3 frontend can't handle sizes larger than 4GB.

Is this really still such an important problem?
We can easily support cross-builds from all 32 bit targets to all
32 bit targets and from 64 bit targets to both 32 and 64 bit targets,
right?

And we do have several 64 bit build machines...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Oct  1 12:46:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 10:46:12 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>, ,
	<1285845869.2729.7.camel@boromir.m3w.org>,
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>,
	<20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
Message-ID: <COL101-W354E7D14E90E16D1BA3F77E6690@phx.gbl>


No, it isn't a big problem, but it is an obvious wart. I'd like to fix it. I know how. It is just "a bit" tedious.
It is common these days to support arbitrary crosses.
I think we should.

However, granted, gcc uses a mix of:
? 64bit long (for 64bit host targeting 64bit)
? 64bit long long (32bit host targeting 64bit) -- easy, esp. in C where long => long long conversion is automatic (given that it is lossless, no problem, imho, but I lost that argument here, meanwhile, most code in the world is written this way and nobody complains...) 
? "double_int" a struct containing two longs (I don't know why they still use this, maybe support 32bit host targeting 64bit without a 64bit long long?)
? gmp -- arbitrary precision (ditto) 

If we "just" use LONGINT more instead of INTEGER, we can get by with less change.
The "more honest" approach is to use Target.Int though.

I'd like to take a stab at it, but I expect it might be invasive, want to make sure it is ok.

?- Jay

----------------------------------------
> Date: Fri, 1 Oct 2010 12:37:23 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>
> Quoting Jay K :
>
> >
> > Really? What technique was employed?
> > The current system doesn't work as I want. As most other compilers now do.
> > You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
> > Right. In the past gcc didn't have such good cross building capabilities.
> > So that might have helped.
> > Now it does. Now cm3cg has no problem crossing arbitrarily.
> > But the cm3 frontend does.
> > A 32bit cm3 frontend can't handle sizes larger than 4GB.
>
> Is this really still such an important problem?
> We can easily support cross-builds from all 32 bit targets to all
> 32 bit targets and from 64 bit targets to both 32 and 64 bit targets,
> right?
>
> And we do have several 64 bit build machines...
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  1 13:17:16 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 01 Oct 2010 13:17:16 +0200
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>
	, <12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
	<COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
Message-ID: <1285931836.14463.20.camel@boromir.m3w.org>

Can we cross-develop on regular basis now?

For example, I would like to develop for Android (what happened with
it?) and just upload packages.

Possible?

On Fri, 2010-10-01 at 10:17 +0000, Jay K wrote:
> Huh? You mean hack, cross once, unhack?
> I want to cross build as a regular occurence. The entire system.
> I already do actually. But currently only enough to get cm3.
> The problems occur if you try to build the entire system.
>   Ok, right, I left one of the hacks in actually.
>   Like TEXTs have a 2GB size limit or such. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  1 13:30:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 11:30:52 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <1285931836.14463.20.camel@boromir.m3w.org>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,,
	<12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>,
	<COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>,
	<1285931836.14463.20.camel@boromir.m3w.org>
Message-ID: <COL101-W631D593E96E1992F179786E6690@phx.gbl>


Yes and no. For most people's point of view, no.


I regularly cross build just enough to build cm3 -- m3core/libm3/m3quake/cm3/m3middle/m3front/m3linker.


The missing pieces:
? - you can't the entire system, there are a small number of errors
? - What this is doing is getting as far as generating assembly source.
?? Assemble, compiler C (including having C library headers), link C (including having C libraries) are left
? as an exercise, and is of varying difficulty.


If you want to cross to Linux, then it isn't too difficult. But I haven't done it much.
If you want to cross to mingw or cygwin it probably isn't too difficult.
If you want to cross to NetBSD, it probably isn't too difficult.
But all these "isn't too difficult" aren't necessarily the same.


The problem is needing a cross C compiler, cross assembler, cross linker, C libraries and C headers.
A cross C compiler that only generates assembly is as easy as Modula-3 -- use gcc.
Cross assembler and linker can often but not always be GNU binutils.
C libraries and C headers can be glibc or newlib or uclibc, shouldn't be too difficult.
For other systems, you copy /usr/lib and /usr/include.
? I have cross compiled to Solaris from Cygwin for example, and from something (I forgot) to Irix I think.
? I have a cross compiler for alpha-vms on my Mac. But finding the headers/libraries was a bit challenging.


On the other hand, on systems like Fedora, Gentoo, Debian, people are somewhat busy as I understand providing
prebuilt cross toolset packages, apt-get install whatever.


As well for iPhone and Android the "native" toolsets are cross.
So these should be easy.


Android looked a bit daunting to get started with though.
I haven't so much as done hello world in Java or C running in an emulator or on hardware.
If someone can walk me through hello world in C running in an emulator, I'd be in a better position to get Modula-3 there.


I also find anything that involves Eclipse daunting. There are too many to choise from, and while I like
that they have an install-free option, it is nice to have an installer when first starting out.



Now then, there is the question of what should Modula-3 distribution format be?
I think the 3.6 format is a good model to strive for.
Distribute a bunch of assembly files and assemble, compile C, link, on the target.
That equates to "useful to just Jay" becoming more useful.
However Olaf's point is valid. We'd need just one 64bit host to cross build all the 64bit distributions.
And there is other work needed to make this so.
?Mainly some scripting to package stuff up.
? Actually Olaf's "workspace" packages might be close to it. But I really don't like there
? being cm3-ws-web, cm3-ws-games, cm3-ws-comm, etc. Too many. Confusing.
?I want just one cm3-target.tar.gz, and I want the web page to sniff my browser
? and point me at the right one (like Firefox download does). Really, I find our
? download pages very hard to wade through. Huge lists of stuff to download.

Anyway.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 1 Oct 2010 13:17:16 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>
> Can we cross-develop on regular basis now?
>
> For example, I would like to develop for Android (what happened with
> it?) and just upload packages.
>
> Possible?
>
> On Fri, 2010-10-01 at 10:17 +0000, Jay K wrote:
> > Huh? You mean hack, cross once, unhack?
> > I want to cross build as a regular occurence. The entire system.
> > I already do actually. But currently only enough to get cm3.
> > The problems occur if you try to build the entire system.
> > Ok, right, I left one of the hacks in actually.
> > Like TEXTs have a 2GB size limit or such.
> --
> Dragi?a Duri? 
>
 		 	   		  

From hosking at cs.purdue.edu  Fri Oct  1 15:59:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Oct 2010 09:59:22 -0400
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W354E7D14E90E16D1BA3F77E6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>, ,
	<1285845869.2729.7.camel@boromir.m3w.org>,
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>,
	<20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
	<COL101-W354E7D14E90E16D1BA3F77E6690@phx.gbl>
Message-ID: <8EAB461C-8FA1-4D6A-864D-B810029D5561@cs.purdue.edu>

I don't think this should be a priority, especially if invasive...

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 1 Oct 2010, at 06:46, Jay K wrote:

> 
> No, it isn't a big problem, but it is an obvious wart. I'd like to fix it. I know how. It is just "a bit" tedious.
> It is common these days to support arbitrary crosses.
> I think we should.
> 
> However, granted, gcc uses a mix of:
>   64bit long (for 64bit host targeting 64bit)
>   64bit long long (32bit host targeting 64bit) -- easy, esp. in C where long => long long conversion is automatic (given that it is lossless, no problem, imho, but I lost that argument here, meanwhile, most code in the world is written this way and nobody complains...) 
>   "double_int" a struct containing two longs (I don't know why they still use this, maybe support 32bit host targeting 64bit without a 64bit long long?)
>   gmp -- arbitrary precision (ditto) 
> 
> If we "just" use LONGINT more instead of INTEGER, we can get by with less change.
> The "more honest" approach is to use Target.Int though.
> 
> I'd like to take a stab at it, but I expect it might be invasive, want to make sure it is ok.
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Fri, 1 Oct 2010 12:37:23 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>> 
>> Quoting Jay K :
>> 
>>> 
>>> Really? What technique was employed?
>>> The current system doesn't work as I want. As most other compilers now do.
>>> You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
>>> Right. In the past gcc didn't have such good cross building capabilities.
>>> So that might have helped.
>>> Now it does. Now cm3cg has no problem crossing arbitrarily.
>>> But the cm3 frontend does.
>>> A 32bit cm3 frontend can't handle sizes larger than 4GB.
>> 
>> Is this really still such an important problem?
>> We can easily support cross-builds from all 32 bit targets to all
>> 32 bit targets and from 64 bit targets to both 32 and 64 bit targets,
>> right?
>> 
>> And we do have several 64 bit build machines...
>> 
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> 
> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101001/e32b06fc/attachment-0001.html>

From hosking at cs.purdue.edu  Fri Oct  1 15:58:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Oct 2010 09:58:36 -0400
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
	<COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
Message-ID: <96B9F209-182F-4422-AC77-ED4071EEAF2E@cs.purdue.edu>

What hack?
Why build the entire system in cross?  That seems overly complicated.  Better to just cross-build the compiler.

On 1 Oct 2010, at 06:17, Jay K wrote:

> 
> Huh? You mean hack, cross once, unhack?
> I want to cross build as a regular occurence. The entire system.
> I already do actually. But currently only enough to get cm3.
> The problems occur if you try to build the entire system.
>   Ok, right, I left one of the hacks in actually.
>   Like TEXTs have a 2GB size limit or such.
> 
> 
> "Regular" cross builds are normal in other environments these days.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>> From: hosking at cs.purdue.edu
>> Date: Thu, 30 Sep 2010 09:42:59 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> Whenever you cross build you should do a subsequent native bootstrap to eliminate those.
>> 
>> On 30 Sep 2010, at 07:14, Jay K wrote:
>> 
>>> 
>>> So..we can't fully cross build a 64bit target from a 32bit host because some code
>>> wants to declare arrays that fill memory, like so that indexing them never fails
>>> an overflow check:
>>> 
>>> 
>>> TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example
>>> 
>>> 
>>> I'm faced with a few choices:
>>> - do nothing
>>> - have the front end pin the sizes to its maximum
>>> Leading to such code to fail if it actually operates on data larger than 2GB
>>> - use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less
>>> - use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long",
>>> (roughly: "long" suffices instead on most 64bit systems)
>>> - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c
>>> 
>>> 
>>> Extremely similarly btw:
>>> 
>>> 
>>> TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example
>>> TYPE T2 = RECORD a,b,c:T1; END;
>>> 
>>> 
>>> which is just to say, it isn't just about total array sizes, but also field offsets.
>>> 
>>> 
>>> (I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...)
>>> 
>>> 
>>> 
>>> I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code.
>>> e.g. m3front/src/types/Type.i3/Info, and then all its users.
>>> 
>>> Should these types use a different and unsafe form?
>>> Do we have a convenient unsafe form?
>>> 
>>> - Jay
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Sun Oct  3 09:00:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 07:00:48 +0000
Subject: [M3devel] declare_constant
Message-ID: <COL101-W58C4E09C2D757EA99ABC2FE66B0@phx.gbl>


The frontend never calls declare_constant.
I wonder if it should be removed.
Presumably all constants are embedded in segments.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Sun Oct  3 10:00:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 08:00:07 +0000
Subject: [M3devel] unnecessary temporaries in m3cc/parse.c
Message-ID: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>


I fail to understand why the following need explicit temporaries:

check_nil
check_lo
check_hi
check_range
check_eq
shift
rotate

probably even:
? round
? floor
? ceiling

but floating point doesn't matter so much.

"stabilize_reference" can be used to avoid recomputing values.

?- Jay
 		 	   		  

From dragisha at m3w.org  Sun Oct  3 11:35:01 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 03 Oct 2010 11:35:01 +0200
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20101003073802.D04B02474003@birch.elegosoft.com>
References: <20101003073802.D04B02474003@birch.elegosoft.com>
Message-ID: <1286098501.14463.74.camel@boromir.m3w.org>

new source -> compiling PickleStubs.m3
../src/pickle/ver2/PickleStubs.m3: In function 'PickleStubs_M3':
../src/pickle/ver2/PickleStubs.m3:599:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3542
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
  m3_backend => 4
m3cc (aka cm3cg) failed compiling: PickleStubs.mc


Lots of these, during ./upgrade.sh, from cvshead.

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sun Oct  3 12:57:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 10:57:29 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1286098501.14463.74.camel@boromir.m3w.org>
References: <20101003073802.D04B02474003@birch.elegosoft.com>,
	<1286098501.14463.74.camel@boromir.m3w.org>
Message-ID: <COL101-W62DE90CD685CAA398BEAEFE66B0@phx.gbl>


ok, sorry, I'm still working on it..










----------------------------------------
> From: dragisha at m3w.org
> To: jkrell at elego.de
> Date: Sun, 3 Oct 2010 11:35:01 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> new source -> compiling PickleStubs.m3
> ../src/pickle/ver2/PickleStubs.m3: In function 'PickleStubs_M3':
> ../src/pickle/ver2/PickleStubs.m3:599:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3542
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> m3_backend => 4
> m3cc (aka cm3cg) failed compiling: PickleStubs.mc
>
>
> Lots of these, during ./upgrade.sh, from cvshead.
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Sun Oct  3 14:47:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 12:47:41 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
Message-ID: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>


It appears that due to e.g.


TYPE Pointer = REF Record;
TYPE Record = RECORD
??? Next: Pointer;
END;


it is possible for the backend to get type declarations "out of order".
? There being no "correct" order, no order without forward references.
It says declare_indirect(Pointer) before declare_record(Record).
? I'm not sure of this exact example, but it does occur.


Currently fields are implicitly within the "current" record.


I think in order to break these cycles, declare_field should contain the uid of their record.


And then we should forward declare all records.
Then indirects to them.
Then their fields.


I'm not sure that solves the general case or not though.


More generally we might want to use this pattern also for objects and proctypes.


It's also likely I can solve this in the backend alone, by running more passes
until everything is resolved.


I keep thinking to myself that I might have to build up in memory
a very faithful rendition of the m3cg calls and iterate over it,
before making the gcc trees.


?


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Sun Oct  3 14:51:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 12:51:52 +0000
Subject: [M3devel] subranges 0..-1?
Message-ID: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>


../src/Common/X.i3: In function 'X_I3':
../src/Common/X.i3:4845:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3567


? gcc_assert (min <= max);

? XClientMessageEvent = RECORD
???? type: int;
???? serial: unsigned_long;??? (* # of last request processed by server *)
???? send_event: Bool;???????? (* true if this came from a SendEvent request *)
???? display: DisplayStar;???? (* Display the event was read from *)
???? window: Window;
???? message_type: Atom;
???? format: int;
???? alignment: ARRAY [0..-1] OF long;
???? data: ARRAY [0..MAX (20 * BYTESIZE (char),
????????????????????????? MAX (10 * BYTESIZE (short),
?????????????????????????????? 5 * BYTESIZE (long))) - 1] OF char; END;


???? alignment: ARRAY [0..-1] OF long;


typedef struct {
??? int type;
??? unsigned long serial;??? /* # of last request processed by server */
??? Bool send_event;??? /* true if this came from a SendEvent request */
??? Display *display;??? /* Display the event was read from */
??? Window window;
??? Atom message_type;
??? int format;
??? union {
??? ??? char b[20];
??? ??? short s[10];
??? ??? long l[5];
??? ??? } data;
} XClientMessageEvent;



eh?


I'll remove the assert.
"Clearly"? the Modula-3 should just use an array of long though for the union?


?- Jay

 		 	   		  

From hosking at cs.purdue.edu  Sun Oct  3 23:02:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 3 Oct 2010 17:02:07 -0400
Subject: [M3devel] declare_constant
In-Reply-To: <COL101-W58C4E09C2D757EA99ABC2FE66B0@phx.gbl>
References: <COL101-W58C4E09C2D757EA99ABC2FE66B0@phx.gbl>
Message-ID: <02D443A4-8D02-45E2-B053-37AEFC3A0A92@cs.purdue.edu>

Or perhaps we should be declaring them...

On 3 Oct 2010, at 03:00, Jay K wrote:

> 
> The frontend never calls declare_constant.
> I wonder if it should be removed.
> Presumably all constants are embedded in segments.
> 
>  - Jay
> 
> 
> 
> 
> 		 	   		  



From hosking at cs.purdue.edu  Sun Oct  3 23:05:40 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 3 Oct 2010 17:05:40 -0400
Subject: [M3devel] unnecessary temporaries in m3cc/parse.c
In-Reply-To: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>
References: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>
Message-ID: <6074704E-AF87-43FF-AE7D-361E8A6CD47D@cs.purdue.edu>

Seems reasonable.  The reasons may be lost in the mists of time...

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 3 Oct 2010, at 04:00, Jay K wrote:

> 
> I fail to understand why the following need explicit temporaries:
> 
> check_nil
> check_lo
> check_hi
> check_range
> check_eq
> shift
> rotate
> 
> probably even:
>   round
>   floor
>   ceiling
> 
> but floating point doesn't matter so much.
> 
> "stabilize_reference" can be used to avoid recomputing values.
> 
>  - Jay
> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101003/3192ceeb/attachment-0001.html>

From dragisha at m3w.org  Sun Oct  3 23:30:31 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 03 Oct 2010 23:30:31 +0200
Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
Message-ID: <1286141431.14463.86.camel@boromir.m3w.org>

upgrade.sh works ok, it looks like.. But during make-bin-dist-min cycle
I am seeing those:

new source -> compiling RT0.i3

 declare_pointer: missing type 0xC2DE134C

 replaying to resolve circular types (pass 1)

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Mon Oct  4 01:23:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 23:23:46 +0000
Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
In-Reply-To: <1286141431.14463.86.camel@boromir.m3w.org>
References: <1286141431.14463.86.camel@boromir.m3w.org>
Message-ID: <COL101-W27F6A2E36D944772EDB520E66B0@phx.gbl>


okok I turned them off

?- Jay



----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Sun, 3 Oct 2010 23:30:31 +0200
> Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
>
> upgrade.sh works ok, it looks like.. But during make-bin-dist-min cycle
> I am seeing those:
>
> new source -> compiling RT0.i3
>
> declare_pointer: missing type 0xC2DE134C
>
> replaying to resolve circular types (pass 1)
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 01:30:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 23:30:50 +0000
Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
In-Reply-To: <1286141431.14463.86.camel@boromir.m3w.org>
References: <1286141431.14463.86.camel@boromir.m3w.org>
Message-ID: <COL101-W3644F16E785D059BC978B9E66B0@phx.gbl>


It's great to have someone else trying this stuff!

Thanks,
?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Sun, 3 Oct 2010 23:30:31 +0200
> Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
>
> upgrade.sh works ok, it looks like.. But during make-bin-dist-min cycle
> I am seeing those:
>
> new source -> compiling RT0.i3
>
> declare_pointer: missing type 0xC2DE134C
>
> replaying to resolve circular types (pass 1)
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 01:44:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 23:44:02 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>
Message-ID: <COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>


I think I'll just solve this in the backend by making a few passes.
Maybe something with specific passes where early passes only pay
attention to certain opcodes, that declare types.

The new/current "replay" stuff will maybe go away.

The new/current keeping of the entire file in memory will stay
unless someone has strong evidence/argument that is shouldn't.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: backend interface vs. types vs. forward references?
> Date: Sun, 3 Oct 2010 12:47:41 +0000
>
>
> It appears that due to e.g.
>
>
> TYPE Pointer = REF Record;
> TYPE Record = RECORD
>     Next: Pointer;
> END;
>
>
> it is possible for the backend to get type declarations "out of order".
>   There being no "correct" order, no order without forward references.
> It says declare_indirect(Pointer) before declare_record(Record).
>   I'm not sure of this exact example, but it does occur.
>
>
> Currently fields are implicitly within the "current" record.
>
>
> I think in order to break these cycles, declare_field should contain the uid of their record.
>
>
> And then we should forward declare all records.
> Then indirects to them.
> Then their fields.
>
>
> I'm not sure that solves the general case or not though.
>
>
> More generally we might want to use this pattern also for objects and proctypes.
>
>
> It's also likely I can solve this in the backend alone, by running more passes
> until everything is resolved.
>
>
> I keep thinking to myself that I might have to build up in memory
> a very faithful rendition of the m3cg calls and iterate over it,
> before making the gcc trees.
>
>
> ?
>
>
>  - Jay
>
>
 		 	   		  

From ttmrichter at gmail.com  Mon Oct  4 04:23:37 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Mon, 4 Oct 2010 10:23:37 +0800
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
Message-ID: <AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>

What does an ARRAY [0..-1] OF <anything> actually look like?

On 3 October 2010 20:51, Jay K <jay.krell at cornell.edu> wrote:

>
> ../src/Common/X.i3: In function 'X_I3':
> ../src/Common/X.i3:4845:0: internal compiler error: in
> m3cg_declare_subrange, at m3cg/parse.c:3567
>
>
>   gcc_assert (min <= max);
>
>   XClientMessageEvent = RECORD
>      type: int;
>      serial: unsigned_long;    (* # of last request processed by server *)
>      send_event: Bool;         (* true if this came from a SendEvent
> request *)
>      display: DisplayStar;     (* Display the event was read from *)
>      window: Window;
>      message_type: Atom;
>      format: int;
>      alignment: ARRAY [0..-1] OF long;
>      data: ARRAY [0..MAX (20 * BYTESIZE (char),
>                           MAX (10 * BYTESIZE (short),
>                                5 * BYTESIZE (long))) - 1] OF char; END;
>
>
>      alignment: ARRAY [0..-1] OF long;
>
>
> typedef struct {
>     int type;
>     unsigned long serial;    /* # of last request processed by server */
>     Bool send_event;    /* true if this came from a SendEvent request */
>     Display *display;    /* Display the event was read from */
>     Window window;
>     Atom message_type;
>     int format;
>     union {
>         char b[20];
>         short s[10];
>         long l[5];
>         } data;
> } XClientMessageEvent;
>
>
>
> eh?
>
>
> I'll remove the assert.
> "Clearly"? the Modula-3 should just use an array of long though for the
> union?
>
>
>  - Jay
>
>




-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101004/220b0cd5/attachment-0001.html>

From hosking at cs.purdue.edu  Mon Oct  4 06:08:50 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 00:08:50 -0400
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>
Message-ID: <1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>

It's an array with no elements, since the subrange [0..-1] is empty.

On 3 Oct 2010, at 22:23, Michael Richter wrote:

> What does an ARRAY [0..-1] OF <anything> actually look like?
> 
> On 3 October 2010 20:51, Jay K <jay.krell at cornell.edu> wrote:
> 
> ../src/Common/X.i3: In function 'X_I3':
> ../src/Common/X.i3:4845:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3567
> 
> 
>   gcc_assert (min <= max);
> 
>   XClientMessageEvent = RECORD
>      type: int;
>      serial: unsigned_long;    (* # of last request processed by server *)
>      send_event: Bool;         (* true if this came from a SendEvent request *)
>      display: DisplayStar;     (* Display the event was read from *)
>      window: Window;
>      message_type: Atom;
>      format: int;
>      alignment: ARRAY [0..-1] OF long;
>      data: ARRAY [0..MAX (20 * BYTESIZE (char),
>                           MAX (10 * BYTESIZE (short),
>                                5 * BYTESIZE (long))) - 1] OF char; END;
> 
> 
>      alignment: ARRAY [0..-1] OF long;
> 
> 
> typedef struct {
>     int type;
>     unsigned long serial;    /* # of last request processed by server */
>     Bool send_event;    /* true if this came from a SendEvent request */
>     Display *display;    /* Display the event was read from */
>     Window window;
>     Atom message_type;
>     int format;
>     union {
>         char b[20];
>         short s[10];
>         long l[5];
>         } data;
> } XClientMessageEvent;
> 
> 
> 
> eh?
> 
> 
> I'll remove the assert.
> "Clearly"? the Modula-3 should just use an array of long though for the union?
> 
> 
>  - Jay
> 
>                                          
> 
> 
> 
> -- 
> "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101004/5a819709/attachment-0001.html>

From jay.krell at cornell.edu  Mon Oct  4 12:35:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 10:35:25 +0000
Subject: [M3devel] unnecessary temporaries in m3cc/parse.c
In-Reply-To: <6074704E-AF87-43FF-AE7D-361E8A6CD47D@cs.purdue.edu>
References: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>,
	<6074704E-AF87-43FF-AE7D-361E8A6CD47D@cs.purdue.edu>
Message-ID: <COL101-W4C498D5F36D9300A3A44FE66C0@phx.gbl>


The first bunch are gone now.
The second few are more work and less interesting. Floating point -- meh.
stabilize_reference I sprinkled all around.

?? - Jay

________________________________
> Subject: Re: [M3devel] unnecessary temporaries in m3cc/parse.c
> From: hosking at cs.purdue.edu
> Date: Sun, 3 Oct 2010 17:05:40 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> Seems reasonable. The reasons may be lost in the mists of time...
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 3 Oct 2010, at 04:00, Jay K wrote:
>
>
> I fail to understand why the following need explicit temporaries:
>
> check_nil
> check_lo
> check_hi
> check_range
> check_eq
> shift
> rotate
>
> probably even:
> round
> floor
> ceiling
>
> but floating point doesn't matter so much.
>
> "stabilize_reference" can be used to avoid recomputing values.
>
> - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 12:41:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 10:41:02 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>, ,
	<1285845869.2729.7.camel@boromir.m3w.org>,
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>,
	<20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
Message-ID: <COL101-w65521D7AAC25DB29CD13B6E66C0@phx.gbl>


 > Olaff
 > We can easily support cross-builds from
 > all 32 bit targets to all
 > 32 bit targets and from 64 bit targets to
 > both 32 and 64 bit targets, right?
 
 Correct. 
 Still, I'm very inclined to fix it. 
 Either Target.Int or LONGINT should be used "everywhere". 
 gcc uses long long heavily internally for this purpose,
  if targeting 64bit from 32bit, though
  it also has available "double_int" and gmp.

 - Jay
 		 	   		  

From wagner at elegosoft.com  Mon Oct  4 16:45:46 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 04 Oct 2010 16:45:46 +0200
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>
Message-ID: <20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> I think I'll just solve this in the backend by making a few passes.
> Maybe something with specific passes where early passes only pay
> attention to certain opcodes, that declare types.

I'm not really happy with multiple passes within the backend just to
make gcc happy. The performance of the gcc backend is already poor
compared to an integrated backend and to what M3 should be able to
achieve. How much will it cost wrt. performance?

> The new/current "replay" stuff will maybe go away.

Hm, I must have missed that.

> The new/current keeping of the entire file in memory will stay
> unless someone has strong evidence/argument that is shouldn't.

Keeping the whole (intermediate code) file in memory should be fine,
unless we get problems for large generated files on small machines
somewhere.

How big are the intermediate files for all our own sources?
Can you write out some statistics?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Mon Oct  4 19:03:08 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 17:03:08 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>
Message-ID: <COL101-W63A85230DF18466658F59BE66C0@phx.gbl>


The passes I'm talking about I think will be fast.
True the backend is very slow but I don't think this will matter.
The earlier will passes will ignore most of the data.
The cost will only be in the extra but ignored serialization.
And even then, it might be better -- if the ordering is a certain way
and guaranteed, once it hits certain opcodes, it will know the types
are all done and start over, without walking each opcode one at a time.

I tried building m3cc on virtual machines with only 256MB and it failed.
I had to up to 384 MB. If I cal recall correctly.

Granted, we don't always build m3cc.

Remember that optimized builds would often use "unit at once"
?compilation, so the entire gcc tree would be in memory.
Now, currently, we never do that for Modula-3, because of a bug
where it throws out functions that are needed to be kept.
But for C/C++ it is not unusual (again, including compiling m3cc).
The tree representation is presumably not much different/smaller than
the m3cg representation. For actual C/C++ there might be a bigger difference,
what with comments/whitespace removed.
But from the gcc point of view, Modula-3 source is already in an encoded binary form.
Granted, the strings are duplicatd.

Still, the access pattern remains linear.
So it doesn't increase working set. Just virtual address space requiremens.

This is something I learned reeently working with large data -- linear access
patterns are what is good and keeps working set down, vs. random access.

Plus, the file gets closed which does free a little of resources, though
probably less than are being additional consumed.

?- Jay

----------------------------------------
> Date: Mon, 4 Oct 2010 16:45:46 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> Quoting Jay K :
>
> > I think I'll just solve this in the backend by making a few passes.
> > Maybe something with specific passes where early passes only pay
> > attention to certain opcodes, that declare types.
>
> I'm not really happy with multiple passes within the backend just to
> make gcc happy. The performance of the gcc backend is already poor
> compared to an integrated backend and to what M3 should be able to
> achieve. How much will it cost wrt. performance?
>
> > The new/current "replay" stuff will maybe go away.
>
> Hm, I must have missed that.
>
> > The new/current keeping of the entire file in memory will stay
> > unless someone has strong evidence/argument that is shouldn't.
>
> Keeping the whole (intermediate code) file in memory should be fine,
> unless we get problems for large generated files on small machines
> somewhere.
>
> How big are the intermediate files for all our own sources?
> Can you write out some statistics?
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 19:16:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 17:16:05 +0000
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
Message-ID: <COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>


It worries me somewhat that we allow zero-sized types.
Including TYPE Foo = RECORD END;
It is reassuring to me that C and C++ doesn't have these.
I don't want to think about what they mean.
Do they make sense to others?

C requires a field. C++ adds a dummy one internally, that it can/must try
to optimize away when inheritance is involved but still.


C++ is interested in the property of pointers not being equal, like:

TYPE T1 = RECORD END;
TYPE T2 = RECORD a,b:T1 END;

VAR a:T1;
ADR(a.b) # ADR(a.a.);

But in Modula-3 they would have the same address.
What does it mean to take the address of something that doesn't exist?
Perhaps it isn't allowed?

As well this kind of thing worries me because Modula-3 truly is
mostly trivially isomorphic with C, which means it is easy to imagine
the gcc backend can handle it. This is an exception.
Sure, there probably is a transform to C, it just isn't obvious to me.
(Granted as well, the gcc backend handles Ada, and Pascal,
so it isn't so limited. Ada at least superficially looks like
Modula-3, I was surprised to see.)

?- Jay

________________________________
> Subject: Re: [M3devel] subranges 0..-1?
> From: hosking at cs.purdue.edu
> Date: Mon, 4 Oct 2010 00:08:50 -0400
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: ttmrichter at gmail.com
>
> It's an array with no elements, since the subrange [0..-1] is empty.
>
> On 3 Oct 2010, at 22:23, Michael Richter wrote:
>
> What does an ARRAY [0..-1] OF actually look like?
>
> On 3 October 2010 20:51, Jay K
> > wrote:
>
> ../src/Common/X.i3: In function 'X_I3':
> ../src/Common/X.i3:4845:0: internal compiler error: in
> m3cg_declare_subrange, at m3cg/parse.c:3567
>
>
> gcc_assert (min <= max);
>
> XClientMessageEvent = RECORD
> type: int;
> serial: unsigned_long; (* # of last request processed by server *)
> send_event: Bool; (* true if this came from a SendEvent
> request *)
> display: DisplayStar; (* Display the event was read from *)
> window: Window;
> message_type: Atom;
> format: int;
> alignment: ARRAY [0..-1] OF long;
> data: ARRAY [0..MAX (20 * BYTESIZE (char),
> MAX (10 * BYTESIZE (short),
> 5 * BYTESIZE (long))) - 1] OF char; END;
>
>
> alignment: ARRAY [0..-1] OF long;
>
>
> typedef struct {
> int type;
> unsigned long serial; /* # of last request processed by server */
> Bool send_event; /* true if this came from a SendEvent request */
> Display *display; /* Display the event was read from */
> Window window;
> Atom message_type;
> int format;
> union {
> char b[20];
> short s[10];
> long l[5];
> } data;
> } XClientMessageEvent;
>
>
>
> eh?
>
>
> I'll remove the assert.
> "Clearly"? the Modula-3 should just use an array of long though for the
> union?
>
>
> - Jay
>
>
>
>
>
> --
> "Perhaps people don't believe this, but throughout all of the
> discussions of entering China our focus has really been what's best for
> the Chinese people. It's not been about our revenue or profit or
> whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 19:23:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 17:23:16 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W63A85230DF18466658F59BE66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>
Message-ID: <COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>


ps: gcc has a very large number of passes over its trees, at least when optimizing.
Like tens or 100+.
The Modula-3 frontend also makes a few passes over everything, just a few.
I don't know where the cost is, but I don't expect to add much. We'll see.
I can try to limit it to not even walk the non-type data.
I should see if the frontend reliably front-loads the type data. It seems to.
We could also put in an end-types opcode to? make it easier to notice.
I think we could also address it in the frontend, by introducing
a type forward declaration call.


> > How big are the intermediate files for all our own sources?


A few months ago I took a quick survey.
This is when I grew the buffer fromwhateve it was to 64K.
I couldn't justify larger because so many would fit in 64K.

I lied somewhat about working set.
If you use a small buffer and iterate in place, your working
set can only grow by the size of the buffer.
If you read the entire thing into memory and walk it linearly,
well, the operating system doesn't necessarily know you won't
walk backwards so it'll let your working set grow, only to throw
out the memory later as needed. This is my rough understanding
based on OS principles. As well, using more address space
has a little extra cost, vs. looping over a small buffer multiple times.

We might might might be able to make some optimizations though,
such as having strings be direct pointers into the buffer instead
of copying them out. There is the matter of the terminal nuls though.
And checking that they fit in the buffer.

> > Can you write out some statistics?


Yeah..
I routinely use cm3 -keep, then just -l target/*c


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com; m3devel at elegosoft.com
> Date: Mon, 4 Oct 2010 17:03:08 +0000
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
>
> The passes I'm talking about I think will be fast.
> True the backend is very slow but I don't think this will matter.
> The earlier will passes will ignore most of the data.
> The cost will only be in the extra but ignored serialization.
> And even then, it might be better -- if the ordering is a certain way
> and guaranteed, once it hits certain opcodes, it will know the types
> are all done and start over, without walking each opcode one at a time.
>
> I tried building m3cc on virtual machines with only 256MB and it failed.
> I had to up to 384 MB. If I cal recall correctly.
>
> Granted, we don't always build m3cc.
>
> Remember that optimized builds would often use "unit at once"
>  compilation, so the entire gcc tree would be in memory.
> Now, currently, we never do that for Modula-3, because of a bug
> where it throws out functions that are needed to be kept.
> But for C/C++ it is not unusual (again, including compiling m3cc).
> The tree representation is presumably not much different/smaller than
> the m3cg representation. For actual C/C++ there might be a bigger difference,
> what with comments/whitespace removed.
> But from the gcc point of view, Modula-3 source is already in an encoded binary form.
> Granted, the strings are duplicatd.
>
> Still, the access pattern remains linear.
> So it doesn't increase working set. Just virtual address space requiremens.
>
> This is something I learned reeently working with large data -- linear access
> patterns are what is good and keeps working set down, vs. random access.
>
> Plus, the file gets closed which does free a little of resources, though
> probably less than are being additional consumed.
>
>  - Jay
>
> ----------------------------------------
> > Date: Mon, 4 Oct 2010 16:45:46 +0200
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] backend interface vs. types vs. forward references?
> >
> > Quoting Jay K :
> >
> > > I think I'll just solve this in the backend by making a few passes.
> > > Maybe something with specific passes where early passes only pay
> > > attention to certain opcodes, that declare types.
> >
> > I'm not really happy with multiple passes within the backend just to
> > make gcc happy. The performance of the gcc backend is already poor
> > compared to an integrated backend and to what M3 should be able to
> > achieve. How much will it cost wrt. performance?
> >
> > > The new/current "replay" stuff will maybe go away.
> >
> > Hm, I must have missed that.
> >
> > > The new/current keeping of the entire file in memory will stay
> > > unless someone has strong evidence/argument that is shouldn't.
> >
> > Keeping the whole (intermediate code) file in memory should be fine,
> > unless we get problems for large generated files on small machines
> > somewhere.
> >
> > How big are the intermediate files for all our own sources?
> > Can you write out some statistics?
> >
> > Olaf
> > --
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >
>
 		 	   		  

From hosking at cs.purdue.edu  Mon Oct  4 19:47:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 13:47:12 -0400
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>
Message-ID: <FC69BD7C-9D55-4642-9F44-0BB86D00DEA1@cs.purdue.edu>

Sure, they make sense.  Just like arrays with no elements.  I don't understand your fearfulness, unless it is just C poisoning your thinking.

On 4 Oct 2010, at 13:16, Jay K wrote:

> 
> It worries me somewhat that we allow zero-sized types.
> Including TYPE Foo = RECORD END;
> It is reassuring to me that C and C++ doesn't have these.
> I don't want to think about what they mean.
> Do they make sense to others?
> 
> C requires a field. C++ adds a dummy one internally, that it can/must try
> to optimize away when inheritance is involved but still.
> 
> 
> C++ is interested in the property of pointers not being equal, like:
> 
> TYPE T1 = RECORD END;
> TYPE T2 = RECORD a,b:T1 END;
> 
> VAR a:T1;
> ADR(a.b) # ADR(a.a.);
> 
> But in Modula-3 they would have the same address.
> What does it mean to take the address of something that doesn't exist?
> Perhaps it isn't allowed?
> 
> As well this kind of thing worries me because Modula-3 truly is
> mostly trivially isomorphic with C, which means it is easy to imagine
> the gcc backend can handle it. This is an exception.
> Sure, there probably is a transform to C, it just isn't obvious to me.
> (Granted as well, the gcc backend handles Ada, and Pascal,
> so it isn't so limited. Ada at least superficially looks like
> Modula-3, I was surprised to see.)
> 
>  - Jay
> 
> ________________________________
>> Subject: Re: [M3devel] subranges 0..-1?
>> From: hosking at cs.purdue.edu
>> Date: Mon, 4 Oct 2010 00:08:50 -0400
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: ttmrichter at gmail.com
>> 
>> It's an array with no elements, since the subrange [0..-1] is empty.
>> 
>> On 3 Oct 2010, at 22:23, Michael Richter wrote:
>> 
>> What does an ARRAY [0..-1] OF actually look like?
>> 
>> On 3 October 2010 20:51, Jay K
>>> wrote:
>> 
>> ../src/Common/X.i3: In function 'X_I3':
>> ../src/Common/X.i3:4845:0: internal compiler error: in
>> m3cg_declare_subrange, at m3cg/parse.c:3567
>> 
>> 
>> gcc_assert (min <= max);
>> 
>> XClientMessageEvent = RECORD
>> type: int;
>> serial: unsigned_long; (* # of last request processed by server *)
>> send_event: Bool; (* true if this came from a SendEvent
>> request *)
>> display: DisplayStar; (* Display the event was read from *)
>> window: Window;
>> message_type: Atom;
>> format: int;
>> alignment: ARRAY [0..-1] OF long;
>> data: ARRAY [0..MAX (20 * BYTESIZE (char),
>> MAX (10 * BYTESIZE (short),
>> 5 * BYTESIZE (long))) - 1] OF char; END;
>> 
>> 
>> alignment: ARRAY [0..-1] OF long;
>> 
>> 
>> typedef struct {
>> int type;
>> unsigned long serial; /* # of last request processed by server */
>> Bool send_event; /* true if this came from a SendEvent request */
>> Display *display; /* Display the event was read from */
>> Window window;
>> Atom message_type;
>> int format;
>> union {
>> char b[20];
>> short s[10];
>> long l[5];
>> } data;
>> } XClientMessageEvent;
>> 
>> 
>> 
>> eh?
>> 
>> 
>> I'll remove the assert.
>> "Clearly"? the Modula-3 should just use an array of long though for the
>> union?
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> 
>> --
>> "Perhaps people don't believe this, but throughout all of the
>> discussions of entering China our focus has really been what's best for
>> the Chinese people. It's not been about our revenue or profit or
>> whatnot."
>> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>> 
> 		 	   		  



From hosking at cs.purdue.edu  Mon Oct  4 19:49:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 13:49:51 -0400
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
Message-ID: <13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>

I see no problem walking the IR trees again to fill in the type information.  Can't you make it part of the lowering pass to GIMPLE?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 4 Oct 2010, at 13:23, Jay K wrote:

> 
> ps: gcc has a very large number of passes over its trees, at least when optimizing.
> Like tens or 100+.
> The Modula-3 frontend also makes a few passes over everything, just a few.
> I don't know where the cost is, but I don't expect to add much. We'll see.
> I can try to limit it to not even walk the non-type data.
> I should see if the frontend reliably front-loads the type data. It seems to.
> We could also put in an end-types opcode to  make it easier to notice.
> I think we could also address it in the frontend, by introducing
> a type forward declaration call.
> 
> 
>>> How big are the intermediate files for all our own sources?
> 
> 
> A few months ago I took a quick survey.
> This is when I grew the buffer fromwhateve it was to 64K.
> I couldn't justify larger because so many would fit in 64K.
> 
> I lied somewhat about working set.
> If you use a small buffer and iterate in place, your working
> set can only grow by the size of the buffer.
> If you read the entire thing into memory and walk it linearly,
> well, the operating system doesn't necessarily know you won't
> walk backwards so it'll let your working set grow, only to throw
> out the memory later as needed. This is my rough understanding
> based on OS principles. As well, using more address space
> has a little extra cost, vs. looping over a small buffer multiple times.
> 
> We might might might be able to make some optimizations though,
> such as having strings be direct pointers into the buffer instead
> of copying them out. There is the matter of the terminal nuls though.
> And checking that they fit in the buffer.
> 
>>> Can you write out some statistics?
> 
> 
> Yeah..
> I routinely use cm3 -keep, then just -l target/*c
> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: wagner at elegosoft.com; m3devel at elegosoft.com
>> Date: Mon, 4 Oct 2010 17:03:08 +0000
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> 
>> The passes I'm talking about I think will be fast.
>> True the backend is very slow but I don't think this will matter.
>> The earlier will passes will ignore most of the data.
>> The cost will only be in the extra but ignored serialization.
>> And even then, it might be better -- if the ordering is a certain way
>> and guaranteed, once it hits certain opcodes, it will know the types
>> are all done and start over, without walking each opcode one at a time.
>> 
>> I tried building m3cc on virtual machines with only 256MB and it failed.
>> I had to up to 384 MB. If I cal recall correctly.
>> 
>> Granted, we don't always build m3cc.
>> 
>> Remember that optimized builds would often use "unit at once"
>> compilation, so the entire gcc tree would be in memory.
>> Now, currently, we never do that for Modula-3, because of a bug
>> where it throws out functions that are needed to be kept.
>> But for C/C++ it is not unusual (again, including compiling m3cc).
>> The tree representation is presumably not much different/smaller than
>> the m3cg representation. For actual C/C++ there might be a bigger difference,
>> what with comments/whitespace removed.
>> But from the gcc point of view, Modula-3 source is already in an encoded binary form.
>> Granted, the strings are duplicatd.
>> 
>> Still, the access pattern remains linear.
>> So it doesn't increase working set. Just virtual address space requiremens.
>> 
>> This is something I learned reeently working with large data -- linear access
>> patterns are what is good and keeps working set down, vs. random access.
>> 
>> Plus, the file gets closed which does free a little of resources, though
>> probably less than are being additional consumed.
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> Date: Mon, 4 Oct 2010 16:45:46 +0200
>>> From: wagner at elegosoft.com
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>>> 
>>> Quoting Jay K :
>>> 
>>>> I think I'll just solve this in the backend by making a few passes.
>>>> Maybe something with specific passes where early passes only pay
>>>> attention to certain opcodes, that declare types.
>>> 
>>> I'm not really happy with multiple passes within the backend just to
>>> make gcc happy. The performance of the gcc backend is already poor
>>> compared to an integrated backend and to what M3 should be able to
>>> achieve. How much will it cost wrt. performance?
>>> 
>>>> The new/current "replay" stuff will maybe go away.
>>> 
>>> Hm, I must have missed that.
>>> 
>>>> The new/current keeping of the entire file in memory will stay
>>>> unless someone has strong evidence/argument that is shouldn't.
>>> 
>>> Keeping the whole (intermediate code) file in memory should be fine,
>>> unless we get problems for large generated files on small machines
>>> somewhere.
>>> 
>>> How big are the intermediate files for all our own sources?
>>> Can you write out some statistics?
>>> 
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>> 
>> 
> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101004/e52c42eb/attachment-0001.html>

From jay.krell at cornell.edu  Mon Oct  4 20:05:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 18:05:57 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>,
	,,<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>,
	, , <20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>, ,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>,
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>,
	<13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>
Message-ID: <COL101-W23F3AFD8BE5D29A26C6E43E66C0@phx.gbl>


I think I understand and I think so.
Rather than lowing to gimple though, it could just be before all that, right?
I mean, walking the gcc trees and converting from "pre-gimple" to "pre-gimple", right?
i.e. not lowering, just transform within same "space"?

What I was talking about though was walking the m3cg opcode IR.
At least the initial type declaration part.

A new m3cg call to just forward declare types might be good too, instead.

?- Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Mon, 4 Oct 2010 13:49:51 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> I see no problem walking the IR trees again to fill in the type
> information. Can't you make it part of the lowering pass to GIMPLE?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 4 Oct 2010, at 13:23, Jay K wrote:
>
>
> ps: gcc has a very large number of passes over its trees, at least when
> optimizing.
> Like tens or 100+.
> The Modula-3 frontend also makes a few passes over everything, just a few.
> I don't know where the cost is, but I don't expect to add much. We'll see.
> I can try to limit it to not even walk the non-type data.
> I should see if the frontend reliably front-loads the type data. It seems to.
> We could also put in an end-types opcode to make it easier to notice.
> I think we could also address it in the frontend, by introducing
> a type forward declaration call.
>
>
> How big are the intermediate files for all our own sources?
>
>
> A few months ago I took a quick survey.
> This is when I grew the buffer fromwhateve it was to 64K.
> I couldn't justify larger because so many would fit in 64K.
>
> I lied somewhat about working set.
> If you use a small buffer and iterate in place, your working
> set can only grow by the size of the buffer.
> If you read the entire thing into memory and walk it linearly,
> well, the operating system doesn't necessarily know you won't
> walk backwards so it'll let your working set grow, only to throw
> out the memory later as needed. This is my rough understanding
> based on OS principles. As well, using more address space
> has a little extra cost, vs. looping over a small buffer multiple times.
>
> We might might might be able to make some optimizations though,
> such as having strings be direct pointers into the buffer instead
> of copying them out. There is the matter of the terminal nuls though.
> And checking that they fit in the buffer.
>
> Can you write out some statistics?
>
>
> Yeah..
> I routinely use cm3 -keep, then just -l target/*c
>
>
> - Jay
>
> ----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com;
> m3devel at elegosoft.com
> Date: Mon, 4 Oct 2010 17:03:08 +0000
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
>
> The passes I'm talking about I think will be fast.
> True the backend is very slow but I don't think this will matter.
> The earlier will passes will ignore most of the data.
> The cost will only be in the extra but ignored serialization.
> And even then, it might be better -- if the ordering is a certain way
> and guaranteed, once it hits certain opcodes, it will know the types
> are all done and start over, without walking each opcode one at a time.
>
> I tried building m3cc on virtual machines with only 256MB and it failed.
> I had to up to 384 MB. If I cal recall correctly.
>
> Granted, we don't always build m3cc.
>
> Remember that optimized builds would often use "unit at once"
> compilation, so the entire gcc tree would be in memory.
> Now, currently, we never do that for Modula-3, because of a bug
> where it throws out functions that are needed to be kept.
> But for C/C++ it is not unusual (again, including compiling m3cc).
> The tree representation is presumably not much different/smaller than
> the m3cg representation. For actual C/C++ there might be a bigger difference,
> what with comments/whitespace removed.
> But from the gcc point of view, Modula-3 source is already in an
> encoded binary form.
> Granted, the strings are duplicatd.
>
> Still, the access pattern remains linear.
> So it doesn't increase working set. Just virtual address space requiremens.
>
> This is something I learned reeently working with large data -- linear access
> patterns are what is good and keeps working set down, vs. random access.
>
> Plus, the file gets closed which does free a little of resources, though
> probably less than are being additional consumed.
>
> - Jay
>
> ----------------------------------------
> Date: Mon, 4 Oct 2010 16:45:46 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> Quoting Jay K :
>
> I think I'll just solve this in the backend by making a few passes.
> Maybe something with specific passes where early passes only pay
> attention to certain opcodes, that declare types.
>
> I'm not really happy with multiple passes within the backend just to
> make gcc happy. The performance of the gcc backend is already poor
> compared to an integrated backend and to what M3 should be able to
> achieve. How much will it cost wrt. performance?
>
> The new/current "replay" stuff will maybe go away.
>
> Hm, I must have missed that.
>
> The new/current keeping of the entire file in memory will stay
> unless someone has strong evidence/argument that is shouldn't.
>
> Keeping the whole (intermediate code) file in memory should be fine,
> unless we get problems for large generated files on small machines
> somewhere.
>
> How big are the intermediate files for all our own sources?
> Can you write out some statistics?
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>
>
>
 		 	   		  

From mika at async.async.caltech.edu  Mon Oct  4 20:12:08 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 04 Oct 2010 11:12:08 -0700
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W481C04C97A03C69858A03BE66C0@phx.gbl> 
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>
Message-ID: <20101004181208.154661A208C@async.async.caltech.edu>

Jay K writes:
>
>It worries me somewhat that we allow zero-sized types.
>Including TYPE Foo =3D RECORD END=3B
>It is reassuring to me that C and C++ doesn't have these.
>I don't want to think about what they mean.
>Do they make sense to others?

Yes, they make a lot of sense.  Not having them means special-casing
any program that generates code.  Obviously a correct program that generates
code including a zero-sized array will never generate an expression
that indexes such an array...

>
>C requires a field. C++ adds a dummy one internally=2C that it can/must try
>to optimize away when inheritance is involved but still.
>
>
>C++ is interested in the property of pointers not being equal=2C like:
>
>TYPE T1 =3D RECORD END=3B
>TYPE T2 =3D RECORD a=2Cb:T1 END=3B
>
>VAR a:T1=3B
>ADR(a.b) # ADR(a.a.)=3B
>
>But in Modula-3 they would have the same address.
>What does it mean to take the address of something that doesn't exist?
>Perhaps it isn't allowed?

This is UNSAFE code, so it means whatever the implementation makes
it mean, including (as far as I'm concerned) a compiler crash, if
that is the easiest thing you can make it mean.  I really wouldn't
worry about the UNSAFE parts of Modula-3 that much...  expected to be
implementation-dependent.  Although I admit it would be better to have
it do something meaningless in this case.  Since T1 is an empty type
there's not much you can do with the address anyhow.

    Mika


From jay.krell at cornell.edu  Mon Oct  4 20:30:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 18:30:31 +0000
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <20101004181208.154661A208C@async.async.caltech.edu>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>,
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>, ,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>,
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>,
	<20101004181208.154661A208C@async.async.caltech.edu>
Message-ID: <COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>


So, I'm not supposed to worry about unsafe stuff..including if the backend and debugging information can? handle it? No.
Unsafe code matters, a lot.

?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> Date: Mon, 4 Oct 2010 11:12:08 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] subranges 0..-1?
>
> Jay K writes:
> >
> >It worries me somewhat that we allow zero-sized types.
> >Including TYPE Foo =3D RECORD END=3B
> >It is reassuring to me that C and C++ doesn't have these.
> >I don't want to think about what they mean.
> >Do they make sense to others?
>
> Yes, they make a lot of sense. Not having them means special-casing
> any program that generates code. Obviously a correct program that generates
> code including a zero-sized array will never generate an expression
> that indexes such an array...
>
> >
> >C requires a field. C++ adds a dummy one internally=2C that it can/must try
> >to optimize away when inheritance is involved but still.
> >
> >
> >C++ is interested in the property of pointers not being equal=2C like:
> >
> >TYPE T1 =3D RECORD END=3B
> >TYPE T2 =3D RECORD a=2Cb:T1 END=3B
> >
> >VAR a:T1=3B
> >ADR(a.b) # ADR(a.a.)=3B
> >
> >But in Modula-3 they would have the same address.
> >What does it mean to take the address of something that doesn't exist?
> >Perhaps it isn't allowed?
>
> This is UNSAFE code, so it means whatever the implementation makes
> it mean, including (as far as I'm concerned) a compiler crash, if
> that is the easiest thing you can make it mean. I really wouldn't
> worry about the UNSAFE parts of Modula-3 that much... expected to be
> implementation-dependent. Although I admit it would be better to have
> it do something meaningless in this case. Since T1 is an empty type
> there's not much you can do with the address anyhow.
>
> Mika
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 21:02:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 19:02:02 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>,
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
Message-ID: <COL101-W3436C5D1E0DEEAD71F2C9FE66C0@phx.gbl>


> ps: gcc has a very large number of passes over its trees, at least when optimizing.

according to the documentation, there
are around 100 SSA form optimization passes and 70 RTL optimization passes
-O2 and -O3 are noticably slower than -O0.
? (and -enable-checking=all is much slower again, and we do still have problems there..)

Bing for "gcc internal passes" and you should find it.

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon Oct  4 22:39:57 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 16:39:57 -0400
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>,
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>, ,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>,
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>,
	<20101004181208.154661A208C@async.async.caltech.edu>
	<COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>
Message-ID: <38B55395-49EA-4B95-BB16-C2A08C279BA5@cs.purdue.edu>

How does the backend handle empty Pascal records?

On 4 Oct 2010, at 14:30, Jay K wrote:

> 
> So, I'm not supposed to worry about unsafe stuff..including if the backend and debugging information can  handle it? No.
> Unsafe code matters, a lot.
> 
>  - Jay
> 
> ----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Mon, 4 Oct 2010 11:12:08 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] subranges 0..-1?
>> 
>> Jay K writes:
>>> 
>>> It worries me somewhat that we allow zero-sized types.
>>> Including TYPE Foo =3D RECORD END=3B
>>> It is reassuring to me that C and C++ doesn't have these.
>>> I don't want to think about what they mean.
>>> Do they make sense to others?
>> 
>> Yes, they make a lot of sense. Not having them means special-casing
>> any program that generates code. Obviously a correct program that generates
>> code including a zero-sized array will never generate an expression
>> that indexes such an array...
>> 
>>> 
>>> C requires a field. C++ adds a dummy one internally=2C that it can/must try
>>> to optimize away when inheritance is involved but still.
>>> 
>>> 
>>> C++ is interested in the property of pointers not being equal=2C like:
>>> 
>>> TYPE T1 =3D RECORD END=3B
>>> TYPE T2 =3D RECORD a=2Cb:T1 END=3B
>>> 
>>> VAR a:T1=3B
>>> ADR(a.b) # ADR(a.a.)=3B
>>> 
>>> But in Modula-3 they would have the same address.
>>> What does it mean to take the address of something that doesn't exist?
>>> Perhaps it isn't allowed?
>> 
>> This is UNSAFE code, so it means whatever the implementation makes
>> it mean, including (as far as I'm concerned) a compiler crash, if
>> that is the easiest thing you can make it mean. I really wouldn't
>> worry about the UNSAFE parts of Modula-3 that much... expected to be
>> implementation-dependent. Although I admit it would be better to have
>> it do something meaningless in this case. Since T1 is an empty type
>> there's not much you can do with the address anyhow.
>> 
>> Mika
> 		 	   		  



From hosking at cs.purdue.edu  Mon Oct  4 22:41:35 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 16:41:35 -0400
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W23F3AFD8BE5D29A26C6E43E66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, , ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, , ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>, ,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>,
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>,
	<13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>
	<COL101-W23F3AFD8BE5D29A26C6E43E66C0@phx.gbl>
Message-ID: <0B6701D7-46BE-458D-8B25-34D2ABD35D77@cs.purdue.edu>

I would avoid a new m3cg.  Just walk the tree as you say.

On 4 Oct 2010, at 14:05, Jay K wrote:

> 
> I think I understand and I think so.
> Rather than lowing to gimple though, it could just be before all that, right?
> I mean, walking the gcc trees and converting from "pre-gimple" to "pre-gimple", right?
> i.e. not lowering, just transform within same "space"?
> 
> What I was talking about though was walking the m3cg opcode IR.
> At least the initial type declaration part.
> 
> A new m3cg call to just forward declare types might be good too, instead.
> 
>  - Jay
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Mon, 4 Oct 2010 13:49:51 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> I see no problem walking the IR trees again to fill in the type
>> information. Can't you make it part of the lowering pass to GIMPLE?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> On 4 Oct 2010, at 13:23, Jay K wrote:
>> 
>> 
>> ps: gcc has a very large number of passes over its trees, at least when
>> optimizing.
>> Like tens or 100+.
>> The Modula-3 frontend also makes a few passes over everything, just a few.
>> I don't know where the cost is, but I don't expect to add much. We'll see.
>> I can try to limit it to not even walk the non-type data.
>> I should see if the frontend reliably front-loads the type data. It seems to.
>> We could also put in an end-types opcode to make it easier to notice.
>> I think we could also address it in the frontend, by introducing
>> a type forward declaration call.
>> 
>> 
>> How big are the intermediate files for all our own sources?
>> 
>> 
>> A few months ago I took a quick survey.
>> This is when I grew the buffer fromwhateve it was to 64K.
>> I couldn't justify larger because so many would fit in 64K.
>> 
>> I lied somewhat about working set.
>> If you use a small buffer and iterate in place, your working
>> set can only grow by the size of the buffer.
>> If you read the entire thing into memory and walk it linearly,
>> well, the operating system doesn't necessarily know you won't
>> walk backwards so it'll let your working set grow, only to throw
>> out the memory later as needed. This is my rough understanding
>> based on OS principles. As well, using more address space
>> has a little extra cost, vs. looping over a small buffer multiple times.
>> 
>> We might might might be able to make some optimizations though,
>> such as having strings be direct pointers into the buffer instead
>> of copying them out. There is the matter of the terminal nuls though.
>> And checking that they fit in the buffer.
>> 
>> Can you write out some statistics?
>> 
>> 
>> Yeah..
>> I routinely use cm3 -keep, then just -l target/*c
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: wagner at elegosoft.com;
>> m3devel at elegosoft.com
>> Date: Mon, 4 Oct 2010 17:03:08 +0000
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> 
>> The passes I'm talking about I think will be fast.
>> True the backend is very slow but I don't think this will matter.
>> The earlier will passes will ignore most of the data.
>> The cost will only be in the extra but ignored serialization.
>> And even then, it might be better -- if the ordering is a certain way
>> and guaranteed, once it hits certain opcodes, it will know the types
>> are all done and start over, without walking each opcode one at a time.
>> 
>> I tried building m3cc on virtual machines with only 256MB and it failed.
>> I had to up to 384 MB. If I cal recall correctly.
>> 
>> Granted, we don't always build m3cc.
>> 
>> Remember that optimized builds would often use "unit at once"
>> compilation, so the entire gcc tree would be in memory.
>> Now, currently, we never do that for Modula-3, because of a bug
>> where it throws out functions that are needed to be kept.
>> But for C/C++ it is not unusual (again, including compiling m3cc).
>> The tree representation is presumably not much different/smaller than
>> the m3cg representation. For actual C/C++ there might be a bigger difference,
>> what with comments/whitespace removed.
>> But from the gcc point of view, Modula-3 source is already in an
>> encoded binary form.
>> Granted, the strings are duplicatd.
>> 
>> Still, the access pattern remains linear.
>> So it doesn't increase working set. Just virtual address space requiremens.
>> 
>> This is something I learned reeently working with large data -- linear access
>> patterns are what is good and keeps working set down, vs. random access.
>> 
>> Plus, the file gets closed which does free a little of resources, though
>> probably less than are being additional consumed.
>> 
>> - Jay
>> 
>> ----------------------------------------
>> Date: Mon, 4 Oct 2010 16:45:46 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> Quoting Jay K :
>> 
>> I think I'll just solve this in the backend by making a few passes.
>> Maybe something with specific passes where early passes only pay
>> attention to certain opcodes, that declare types.
>> 
>> I'm not really happy with multiple passes within the backend just to
>> make gcc happy. The performance of the gcc backend is already poor
>> compared to an integrated backend and to what M3 should be able to
>> achieve. How much will it cost wrt. performance?
>> 
>> The new/current "replay" stuff will maybe go away.
>> 
>> Hm, I must have missed that.
>> 
>> The new/current keeping of the entire file in memory will stay
>> unless someone has strong evidence/argument that is shouldn't.
>> 
>> Keeping the whole (intermediate code) file in memory should be fine,
>> unless we get problems for large generated files on small machines
>> somewhere.
>> 
>> How big are the intermediate files for all our own sources?
>> Can you write out some statistics?
>> 
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> 
>> 
>> 
>> 
> 		 	   		  



From mika at async.async.caltech.edu  Mon Oct  4 23:16:27 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 04 Oct 2010 14:16:27 -0700
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W169957CE63F370DBAF099FE66C0@phx.gbl> 
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>,
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>, ,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>,
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>,
	<20101004181208.154661A208C@async.async.caltech.edu>
	<COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>
Message-ID: <20101004211627.935681A208C@async.async.caltech.edu>

Of course unsafe code matters.

But does the particular example of unsafe code (ADR of a zero-sized
object) matter?  No, because:

1. For human-written code we use your argument.  "Don't do that"

2. Don't generate UNSAFE code by machine.  Or if you must be as careful
   as implied by 1.

     Mika

Jay K writes:
>
>So=2C I'm not supposed to worry about unsafe stuff..including if the backen=
>d and debugging information can=A0 handle it? No.
>Unsafe code matters=2C a lot.
>
>=A0- Jay
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Mon=2C 4 Oct 2010 11:12:08 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] subranges 0..-1?
>>
>> Jay K writes:
>> >
>> >It worries me somewhat that we allow zero-sized types.
>> >Including TYPE Foo =3D3D RECORD END=3D3B
>> >It is reassuring to me that C and C++ doesn't have these.
>> >I don't want to think about what they mean.
>> >Do they make sense to others?
>>
>> Yes=2C they make a lot of sense. Not having them means special-casing
>> any program that generates code. Obviously a correct program that generat=
>es
>> code including a zero-sized array will never generate an expression
>> that indexes such an array...
>>
>> >
>> >C requires a field. C++ adds a dummy one internally=3D2C that it can/mus=
>t try
>> >to optimize away when inheritance is involved but still.
>> >
>> >
>> >C++ is interested in the property of pointers not being equal=3D2C like:
>> >
>> >TYPE T1 =3D3D RECORD END=3D3B
>> >TYPE T2 =3D3D RECORD a=3D2Cb:T1 END=3D3B
>> >
>> >VAR a:T1=3D3B
>> >ADR(a.b) # ADR(a.a.)=3D3B
>> >
>> >But in Modula-3 they would have the same address.
>> >What does it mean to take the address of something that doesn't exist?
>> >Perhaps it isn't allowed?
>>
>> This is UNSAFE code=2C so it means whatever the implementation makes
>> it mean=2C including (as far as I'm concerned) a compiler crash=2C if
>> that is the easiest thing you can make it mean. I really wouldn't
>> worry about the UNSAFE parts of Modula-3 that much... expected to be
>> implementation-dependent. Although I admit it would be better to have
>> it do something meaningless in this case. Since T1 is an empty type
>> there's not much you can do with the address anyhow.
>>
>> Mika
> 		 	   		  =


From jay.krell at cornell.edu  Tue Oct  5 11:00:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 09:00:40 +0000
Subject: [M3devel] hardware clearance?
Message-ID: <COL101-W32FCFBBE44FBF546E07C71E66D0@phx.gbl>


Hey folks.
I have an impending possible need to drastically rapidly cleanup my place.
One of the biggest steps I can take is getting rid of hardware.


Anyone interested?
For free?


It is a quite a mix.? All from eBay over past 2 or so years.
Much has been seen to work, a little has been seen not work, some
has never been tried. Many have not been powered on for months/years.
All have at least some memory/hard drive, some have optical drive,
?or some I'd use external SCSI CD-ROM drive.


SPARC64, PPC64 IA64, PPC, Alpha, MIPS. Stuff capable
of running AIX, Irix, HP-UX, AMD64, VMS, Tru64, Linux,
OpenBSD, FreeBSD, NetBSD, Solaris.

Laptops I can keep.


SPARC64:
? 3x: have run Linux, OpenBSD, Solaris a while
? includes two Hudson nodes (Linux, Solaris, not OpenBSD)
? could also surely run NetBSD, FreeBSD
? at least 4 machines, not all of which have been used 
? both "workstation" and 1U form factors 
? 
? 
MIPS/SGI:
?3 x O2 and 2 x Fuel (much faster)
?? 2 x O2 never used, or 1x might be broken
?? (when I tried to install Linux or NetBSD
?? on an O2, it powered off and would never power
?? back on; OpenBSD proved easier to install) 
?O2 running OpenBSD, used to run Irix
?? should also be viable for NetBSD, Linux
?Fuel running Irix, could also run OpenBSD
?Fuel is much much faster.
?Irix you can bootstrap up to gcc by using some
? seemingly accidentally there C compiler. 

?
IA64:
?2x; was able to run Linux (Debian) on both.
?Probably viable for VMS, HP-UX, FreeBSD,
?? though I attempted HP-UX and FreeBSD, no luck.
?I might keep one of these.
?One of them lacks video out, must install over serial console.
I think 2U form factors (certainly boxy); heavy 


HPPA:
? one machine, was able to run Linux and HP-UX on it
? no video out, must install over serial console
? 1U or 2U 
? HP-UX can be bootstrapped up to current gcc using in-box K&R cc (via gcc 3.x).


AMD64:
?one Sun workstation, some decent specs


PPC64:
?iMac G5, running Darwin, should be viable for others (e.g. Linux)
?
?
PPC64:
? IBM pSeries workstation; running AIX 5.3, should be viable for others (e.g. Linux)
? This machine seemed to overheat and poweroff, e.g. when building gcc, but
? I did manage to get it working pretty well.


Alpha:
?3x or 4x.
?I only ever tried to use one of them and it didn't seem to work.
?2 are "workstation" size, 2 are the nicer smaller DS10L.


68K/Mac:
? 2x that I don't anticipate anything happening with.
? 
? 
I can also probably spare some Mac/PPC laptops.
? One of which is broken.
? 

I'd rather not lose too much on shipping. But flexible.
I'd rather ship as much as possible to same place. But flexible.
I'd rather reserve right of return, in case I get more space and time,
? but the odds of this mattering is generally decreasing.
? 

Rather than wiping and pulling hard drives, I'll probably just
change SSH keys.


Thanks and sorry of this is off-topic.
?- Jay




 		 	   		  

From wagner at elegosoft.com  Tue Oct  5 12:35:45 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 05 Oct 2010 12:35:45 +0200
Subject: [M3devel] compilation failure on Solaris
Message-ID: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>

There are segmentation faults during compilation of Lex.m3, see:

http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console

=== package m3-libs/libm3 ===
  +++ cm3 -build  
-DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS  && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'   
+++
../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
   m3_backend => 4
m3cc (aka cm3cg) failed compiling: Lex.mc
../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
   m3_backend => 4
m3cc (aka cm3cg) failed compiling: FmtBuf.mc

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From dragisha at m3w.org  Tue Oct  5 15:32:30 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 05 Oct 2010 15:32:30 +0200
Subject: [M3devel] m3gap.... what is it and what does this mean?
Message-ID: <1286285550.3514.20.camel@boromir.m3w.org>

(gdb) p event
$1 = {type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 = 
    {<No data fields>}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {<No data fields>}, 
  string = 0xa <Address 0xa out of bounds>, hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {<No data fields>}}


 VAR
   event: Gdk.EventKey;

  EventKey = RECORD 
    type: EventType;
    window: WindowStar;
    send_event: char;
    time: unsigned_long_int;  
    state: unsigned_int;
    keyval: unsigned_int;
    length: int;
    string: char_star;
    hardware_keycode: unsigned_short_int;
    group: unsigned_char;
  END;

also with m3gdb....

(m3gdb) p event
$1 = {4type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x0,
send_event = 0 '\000', 
  _m3gap_136_56 = {<No data fields>}, time = 49, state = -937844736,
keyval = 32616, length = 23801648, 
  _m3gap_352_32 = {<No data fields>}, string = 0x7f68c839be10 "\001
\000", hardware_keycode = 0, group = 0 '\000', 
  _m3gap_472_40 = {<No data fields>}}

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Tue Oct  5 16:48:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 14:48:41 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286285550.3514.20.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>
Message-ID: <COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>


Hey, look, until August, stock gdb never showed any fields!

The front does layout, it might tell the backend:

struct {
? integer a at offset 4, size 4
? integer b at offset 12, size 4
}

in which case the backend will generate a "gap" field at offset 8, size 4

I suspect we might not have to generate the fields.
I'm nervous that the backend might do its own layout and move up b to offset 8 otherwise.
And there was other code in the backing doing similar.

We are in complete control of the name.
If you want we can call it "_m3_padding_for_alignment"
or "-m3_nothing_to_see_here"
or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)

?- Jay




----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Tue, 5 Oct 2010 15:32:30 +0200
> Subject: [M3devel] m3gap.... what is it and what does this mean?
>
> (gdb) p event
> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 =
> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {},
> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>
>
> VAR
> event: Gdk.EventKey;
>
> EventKey = RECORD
> type: EventType;
> window: WindowStar;
> send_event: char;
> time: unsigned_long_int;
> state: unsigned_int;
> keyval: unsigned_int;
> length: int;
> string: char_star;
> hardware_keycode: unsigned_short_int;
> group: unsigned_char;
> END;
>
> also with m3gdb....
>
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> send_event = 0 '\000',
> _m3gap_136_56 = {}, time = 49, state = -937844736,
> keyval = 32616, length = 23801648,
> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
> \000", hardware_keycode = 0, group = 0 '\000',
> _m3gap_472_40 = {}}
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From rodney_bates at lcwb.coop  Tue Oct  5 21:26:41 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 05 Oct 2010 14:26:41 -0500
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	<COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>
Message-ID: <4CAB7BF1.3050801@lcwb.coop>



Jay K wrote:
> Hey, look, until August, stock gdb never showed any fields!
> 
> The front does layout, it might tell the backend:
> 
> struct {
>   integer a at offset 4, size 4
>   integer b at offset 12, size 4
> }
> 
> in which case the backend will generate a "gap" field at offset 8, size 4
> 
> I suspect we might not have to generate the fields.
> I'm nervous that the backend might do its own layout and move up b to offset 8 otherwise.
> And there was other code in the backing doing similar.
> 
> We are in complete control of the name.
> If you want we can call it "_m3_padding_for_alignment"
> or "-m3_nothing_to_see_here"
> or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)

I doubt it, but they might need to be valid linker identifiers.  If there is a
character that is not legal in Modula-3 identifiers but legal here, it would be nice
to use it in generated things like this.  Then a debugger could normally suppress
displaying it, yet not be fooled by a Modula-3 programmer's actually declaring, e.g.,
_m3gap_8_56 in source code.  There are other places this comes up.

> 
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> From: dragisha at m3w.org
>> To: m3devel at elegosoft.com
>> Date: Tue, 5 Oct 2010 15:32:30 +0200
>> Subject: [M3devel] m3gap.... what is it and what does this mean?
>>
>> (gdb) p event
>> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 =
>> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {},
>> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>>
>>
>> VAR
>> event: Gdk.EventKey;
>>
>> EventKey = RECORD
>> type: EventType;
>> window: WindowStar;
>> send_event: char;
>> time: unsigned_long_int;
>> state: unsigned_int;
>> keyval: unsigned_int;
>> length: int;
>> string: char_star;
>> hardware_keycode: unsigned_short_int;
>> group: unsigned_char;
>> END;
>>
>> also with m3gdb....
>>
>> (m3gdb) p event
>> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
>> send_event = 0 '\000',
>> _m3gap_136_56 = {}, time = 49, state = -937844736,
>> keyval = 32616, length = 23801648,
>> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
>> \000", hardware_keycode = 0, group = 0 '\000',
>> _m3gap_472_40 = {}}
>>
>> --
>> Dragi?a Duri? 
>>
>  		 	   		  


From rodney_bates at lcwb.coop  Tue Oct  5 21:29:22 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 05 Oct 2010 14:29:22 -0500
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286285550.3514.20.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>
Message-ID: <4CAB7C92.7040305@lcwb.coop>

Are the gdb and m3gdb prints for the same value of 'event'?   Several of the fields show different
values.

Dragi?a Duri? wrote:
> (gdb) p event
> $1 = {type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 = 
>     {<No data fields>}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {<No data fields>}, 
>   string = 0xa <Address 0xa out of bounds>, hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {<No data fields>}}
> 
> 
>  VAR
>    event: Gdk.EventKey;
> 
>   EventKey = RECORD 
>     type: EventType;
>     window: WindowStar;
>     send_event: char;
>     time: unsigned_long_int;  
>     state: unsigned_int;
>     keyval: unsigned_int;
>     length: int;
>     string: char_star;
>     hardware_keycode: unsigned_short_int;
>     group: unsigned_char;
>   END;
> 
> also with m3gdb....
> 
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x0,
> send_event = 0 '\000', 
>   _m3gap_136_56 = {<No data fields>}, time = 49, state = -937844736,
> keyval = 32616, length = 23801648, 
>   _m3gap_352_32 = {<No data fields>}, string = 0x7f68c839be10 "\001
> \000", hardware_keycode = 0, group = 0 '\000', 
>   _m3gap_472_40 = {<No data fields>}}
> 


From hosking at cs.purdue.edu  Tue Oct  5 22:04:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 5 Oct 2010 16:04:06 -0400
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <4CAB7BF1.3050801@lcwb.coop>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	<COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>
	<4CAB7BF1.3050801@lcwb.coop>
Message-ID: <291C297F-27A1-4F27-9D67-2F0C11ED1F3A@cs.purdue.edu>

M3 ids cannot begin with "_".

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 5 Oct 2010, at 15:26, Rodney M. Bates wrote:

> 
> 
> Jay K wrote:
>> Hey, look, until August, stock gdb never showed any fields!
>> The front does layout, it might tell the backend:
>> struct {
>>  integer a at offset 4, size 4
>>  integer b at offset 12, size 4
>> }
>> in which case the backend will generate a "gap" field at offset 8, size 4
>> I suspect we might not have to generate the fields.
>> I'm nervous that the backend might do its own layout and move up b to offset 8 otherwise.
>> And there was other code in the backing doing similar.
>> We are in complete control of the name.
>> If you want we can call it "_m3_padding_for_alignment"
>> or "-m3_nothing_to_see_here"
>> or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)
> 
> I doubt it, but they might need to be valid linker identifiers.  If there is a
> character that is not legal in Modula-3 identifiers but legal here, it would be nice
> to use it in generated things like this.  Then a debugger could normally suppress
> displaying it, yet not be fooled by a Modula-3 programmer's actually declaring, e.g.,
> _m3gap_8_56 in source code.  There are other places this comes up.
> 
>> - Jay
>> ----------------------------------------
>>> From: dragisha at m3w.org
>>> To: m3devel at elegosoft.com
>>> Date: Tue, 5 Oct 2010 15:32:30 +0200
>>> Subject: [M3devel] m3gap.... what is it and what does this mean?
>>> 
>>> (gdb) p event
>>> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 =
>>> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {},
>>> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>>> 
>>> 
>>> VAR
>>> event: Gdk.EventKey;
>>> 
>>> EventKey = RECORD
>>> type: EventType;
>>> window: WindowStar;
>>> send_event: char;
>>> time: unsigned_long_int;
>>> state: unsigned_int;
>>> keyval: unsigned_int;
>>> length: int;
>>> string: char_star;
>>> hardware_keycode: unsigned_short_int;
>>> group: unsigned_char;
>>> END;
>>> 
>>> also with m3gdb....
>>> 
>>> (m3gdb) p event
>>> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
>>> send_event = 0 '\000',
>>> _m3gap_136_56 = {}, time = 49, state = -937844736,
>>> keyval = 32616, length = 23801648,
>>> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
>>> \000", hardware_keycode = 0, group = 0 '\000',
>>> _m3gap_472_40 = {}}
>>> 
>>> --
>>> Dragi?a Duri? 
>> 		 	   		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101005/18a08712/attachment-0001.html>

From dragisha at m3w.org  Tue Oct  5 22:58:54 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 05 Oct 2010 22:58:54 +0200
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <4CAB7C92.7040305@lcwb.coop>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	<4CAB7C92.7040305@lcwb.coop>
Message-ID: <1286312334.3514.35.camel@boromir.m3w.org>

It was same debugging path, but event is X event, so...

On Tue, 2010-10-05 at 14:29 -0500, Rodney M. Bates wrote:
> Are the gdb and m3gdb prints for the same value of 'event'?   Several
> of the fields show different
> values.
> 
> Dragi?a Duri? wrote:
> > (gdb) p event 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Wed Oct  6 00:53:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 22:53:56 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286312334.3514.35.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, <4CAB7C92.7040305@lcwb.coop>,
	<1286312334.3514.35.camel@boromir.m3w.org>
Message-ID: <COL101-W17C90050417FE64E79E72E66D0@phx.gbl>


1) Let's not be too quick to assume the new debugging stuff is correct.
? I just started it in August, in response to internal compiler errors passing records by value on SPARC64.
? (seems unrelated, but it isn't; there isn't really "debug" stuff in gcc backends, there are merely
? types in the trees, and we were creating records with size but not fields at all, pretty poor
? gcc citizens imho...)
? Though they probably often are correct. I know the level of indirection is sometimes wrong though, like
? on record parameters.

2) The numbers are bit offset and bit size, so not as big as you might think.
I can make them trivially byte offsets, if they are multiples of 8, at the cost
of possible confusion when they aren't.
Or they can just be called _m3gap1, _m3gap2, numbered either per-unit
or per-type.

I could also try not putting them in at all, but merely bumping the offset
of the next field in the same way as current and hoping backend
doesn't relayout and move them toward the start.

?- Jay



----------------------------------------
> From: dragisha at m3w.org
> To: rodney_bates at lcwb.coop
> Date: Tue, 5 Oct 2010 22:58:54 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... what is it and what does this mean?
>
> It was same debugging path, but event is X event, so...
>
> On Tue, 2010-10-05 at 14:29 -0500, Rodney M. Bates wrote:
> > Are the gdb and m3gdb prints for the same value of 'event'? Several
> > of the fields show different
> > values.
> >
> > Dragi?a Duri? wrote:
> > > (gdb) p event
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Wed Oct  6 00:49:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 22:49:57 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <291C297F-27A1-4F27-9D67-2F0C11ED1F3A@cs.purdue.edu>
References: <1286285550.3514.20.camel@boromir.m3w.org>,
	<COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>,
	<4CAB7BF1.3050801@lcwb.coop>,
	<291C297F-27A1-4F27-9D67-2F0C11ED1F3A@cs.purdue.edu>
Message-ID: <COL101-W55C57390007CB07BEF6C3DE66D0@phx.gbl>


The names are generated in the backend.
Use of leading underscore is therefore good -- it can't clash with "real" data.

?- Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 5 Oct 2010 16:04:06 -0400
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... what is it and what does this mean?
>
> M3 ids cannot begin with "_".
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 5 Oct 2010, at 15:26, Rodney M. Bates wrote:
>
>
>
> Jay K wrote:
> Hey, look, until August, stock gdb never showed any fields!
> The front does layout, it might tell the backend:
> struct {
> integer a at offset 4, size 4
> integer b at offset 12, size 4
> }
> in which case the backend will generate a "gap" field at offset 8, size 4
> I suspect we might not have to generate the fields.
> I'm nervous that the backend might do its own layout and move up b to
> offset 8 otherwise.
> And there was other code in the backing doing similar.
> We are in complete control of the name.
> If you want we can call it "_m3_padding_for_alignment"
> or "-m3_nothing_to_see_here"
> or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)
>
> I doubt it, but they might need to be valid linker identifiers. If
> there is a
> character that is not legal in Modula-3 identifiers but legal here, it
> would be nice
> to use it in generated things like this. Then a debugger could
> normally suppress
> displaying it, yet not be fooled by a Modula-3 programmer's actually
> declaring, e.g.,
> _m3gap_8_56 in source code. There are other places this comes up.
>
> - Jay
> ----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Tue, 5 Oct 2010 15:32:30 +0200
> Subject: [M3devel] m3gap.... what is it and what does this mean?
>
> (gdb) p event
> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event =
> 0 '\000', _m3gap_136_56 =
> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024,
> _m3gap_352_32 = {},
> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>
>
> VAR
> event: Gdk.EventKey;
>
> EventKey = RECORD
> type: EventType;
> window: WindowStar;
> send_event: char;
> time: unsigned_long_int;
> state: unsigned_int;
> keyval: unsigned_int;
> length: int;
> string: char_star;
> hardware_keycode: unsigned_short_int;
> group: unsigned_char;
> END;
>
> also with m3gdb....
>
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> send_event = 0 '\000',
> _m3gap_136_56 = {}, time = 49, state = -937844736,
> keyval = 32616, length = 23801648,
> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
> \000", hardware_keycode = 0, group = 0 '\000',
> _m3gap_472_40 = {}}
>
> --
> Dragi?a Duri?
>
>
 		 	   		  

From dragisha at m3w.org  Wed Oct  6 01:48:56 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 06 Oct 2010 01:48:56 +0200
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <COL101-W17C90050417FE64E79E72E66D0@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	, <4CAB7C92.7040305@lcwb.coop>,
	<1286312334.3514.35.camel@boromir.m3w.org>
	<COL101-W17C90050417FE64E79E72E66D0@phx.gbl>
Message-ID: <1286322536.3514.41.camel@boromir.m3w.org>

They are nice as they are, as long as debugging works. Information on
alignment is good to have.

On Tue, 2010-10-05 at 22:53 +0000, Jay K wrote:
> 2) The numbers are bit offset and bit size, so not as big as you might
> think.
> I can make them trivially byte offsets, if they are multiples of 8, at
> the cost
> of possible confusion when they aren't.
> Or they can just be called _m3gap1, _m3gap2, numbered either per-unit
> or per-type.
> 
> I could also try not putting them in at all, but merely bumping the
> offset
> of the next field in the same way as current and hoping backend
> doesn't relayout and move them toward the start. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Wed Oct  6 03:10:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 01:10:30 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286322536.3514.41.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>,,
	<4CAB7C92.7040305@lcwb.coop>, ,
	<1286312334.3514.35.camel@boromir.m3w.org>,
	<COL101-W17C90050417FE64E79E72E66D0@phx.gbl>,
	<1286322536.3514.41.camel@boromir.m3w.org>
Message-ID: <COL101-W27409A49660B73E76EDE1DE66E0@phx.gbl>


Implied tedious request:
  write some code
  including printing out the values with IO. or RTIO.
  step through
  view in debugger
  verify it all matches
  think about how enums should appear, they are perhaps too short now
  Try subranges, enums, objects, records, fixed arrays, open arrays.
    I'm positive not all of that works though, e.g. arrays for certain. 
 
 - Jay



----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Wed, 6 Oct 2010 01:48:56 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... what is it and what does this mean?
>
> They are nice as they are, as long as debugging works. Information on
> alignment is good to have.
>
> On Tue, 2010-10-05 at 22:53 +0000, Jay K wrote:
> > 2) The numbers are bit offset and bit size, so not as big as you might
> > think.
> > I can make them trivially byte offsets, if they are multiples of 8, at
> > the cost
> > of possible confusion when they aren't.
> > Or they can just be called _m3gap1, _m3gap2, numbered either per-unit
> > or per-type.
> >
> > I could also try not putting them in at all, but merely bumping the
> > offset
> > of the next field in the same way as current and hoping backend
> > doesn't relayout and move them toward the start.
> --
> Dragi?a Duri? 
> 		 	   		  

From jay.krell at cornell.edu  Wed Oct  6 11:20:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 09:20:14 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
Message-ID: <COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>


I see. It occurs even on a cross build.
It should be better now -- by avoiding certain large changes on this platform.
A C generating backend is getting ever more tempting..

?- Jay

----------------------------------------
> Date: Tue, 5 Oct 2010 12:35:45 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] compilation failure on Solaris
>
> There are segmentation faults during compilation of Lex.m3, see:
>
> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>
> === package m3-libs/libm3 ===
> +++ cm3 -build
> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> +++
> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> m3_backend => 4
> m3cc (aka cm3cg) failed compiling: Lex.mc
> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> m3_backend => 4
> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From hosking at cs.purdue.edu  Wed Oct  6 15:07:31 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 09:07:31 -0400
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>
Message-ID: <766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>

Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"?  I am wary of special-casing builds of a system as complex as gcc depending on target.

On 6 Oct 2010, at 05:20, Jay K wrote:

> 
> I see. It occurs even on a cross build.
> It should be better now -- by avoiding certain large changes on this platform.
> A C generating backend is getting ever more tempting..
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Tue, 5 Oct 2010 12:35:45 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] compilation failure on Solaris
>> 
>> There are segmentation faults during compilation of Lex.m3, see:
>> 
>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>> 
>> === package m3-libs/libm3 ===
>> +++ cm3 -build
>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
>> +++
>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> m3_backend => 4
>> m3cc (aka cm3cg) failed compiling: Lex.mc
>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> m3_backend => 4
>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>> 
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> 
> 		 	   		  



From jay.krell at cornell.edu  Wed Oct  6 15:24:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 13:24:30 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>
Message-ID: <COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>


It isn't easy. I'm lazy.
I flip one thing and voila cm3 crashes.
I compare e.g. m3core before/after, but there are many changes.

There have been significant changes since August -- starting to provide half decent type information in the trees.
The ramifications of this are potentially very large, and they seem to vary per-target.

Used to be records never had any fields, just a size. That was probably good at tying the compiler's hands,
but it was bad for debugging with regular gdb.

Plus the long time we used volatile.
Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
until relatively recently (nested functions that gcc thinks are unused, but are referenced
from the module data).

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 09:07:31 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] compilation failure on Solaris
>
> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
>
> On 6 Oct 2010, at 05:20, Jay K wrote:
>
> >
> > I see. It occurs even on a cross build.
> > It should be better now -- by avoiding certain large changes on this platform.
> > A C generating backend is getting ever more tempting..
> >
> > - Jay
> >
> > ----------------------------------------
> >> Date: Tue, 5 Oct 2010 12:35:45 +0200
> >> From: wagner at elegosoft.com
> >> To: m3devel at elegosoft.com
> >> Subject: [M3devel] compilation failure on Solaris
> >>
> >> There are segmentation faults during compilation of Lex.m3, see:
> >>
> >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
> >>
> >> === package m3-libs/libm3 ===
> >> +++ cm3 -build
> >> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> >> +++
> >> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See for instructions.
> >> m3_backend => 4
> >> m3cc (aka cm3cg) failed compiling: Lex.mc
> >> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See for instructions.
> >> m3_backend => 4
> >> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
> >>
> >> Olaf
> >> --
> >> Olaf Wagner -- elego Software Solutions GmbH
> >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>
> >
>
 		 	   		  

From jay.krell at cornell.edu  Wed Oct  6 15:30:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 13:30:00 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
Message-ID: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>


some random notes

Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
? Easy test is to run cm3 without a neighboring cm3.cfg and the error
? is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg

Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
? Same easy test, but it crashes upon first attempt to raise an exception.

Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
? NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
? 
Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
? Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.

Meanwhile I think many other targets are working ok with 4.5.
Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Wed Oct  6 16:34:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 10:34:45 -0400
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>
Message-ID: <43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>

I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated. 

Sent from my iPhone

On Oct 6, 2010, at 9:24 AM, Jay K <jay.krell at cornell.edu> wrote:

> Plus the long time we used volatile.
> Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
> until relatively recently (nested functions that gcc thinks are unused, but are referenced
> from the module data).
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 6 Oct 2010 09:07:31 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] compilation failure on Solaris
>> 
>> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
>> 
>> On 6 Oct 2010, at 05:20, Jay K wrote:
>> 
>>> 
>>> I see. It occurs even on a cross build.
>>> It should be better now -- by avoiding certain large changes on this platform.
>>> A C generating backend is getting ever more tempting..
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
>>>> From: wagner at elegosoft.com
>>>> To: m3devel at elegosoft.com
>>>> Subject: [M3devel] compilation failure on Solaris
>>>> 
>>>> There are segmentation faults during compilation of Lex.m3, see:
>>>> 
>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>>>> 
>>>> === package m3-libs/libm3 ===
>>>> +++ cm3 -build
>>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
>>>> +++
>>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
>>>> Please submit a full bug report,
>>>> with preprocessed source if appropriate.
>>>> See for instructions.
>>>> m3_backend => 4
>>>> m3cc (aka cm3cg) failed compiling: Lex.mc
>>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
>>>> Please submit a full bug report,
>>>> with preprocessed source if appropriate.
>>>> See for instructions.
>>>> m3_backend => 4
>>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>>>> 
>>>> Olaf
>>>> --
>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>>> 
>>> 
>> 
>                         


From hosking at cs.purdue.edu  Wed Oct  6 16:48:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 10:48:21 -0400
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
Message-ID: <3A129857-64E9-49C3-BEA3-71BFFCE4E282@cs.purdue.edu>



On 6 Oct 2010, at 09:30, Jay K wrote:

> 
> some random notes
> 
> Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
>   Easy test is to run cm3 without a neighboring cm3.cfg and the error
>   is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg

Used not to break.  I did test this at one point.

> Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
>   Same easy test, but it crashes upon first attempt to raise an exception.
> 
> Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
>   NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
>   
> Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
>   Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> 
> Meanwhile I think many other targets are working ok with 4.5.
> Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Wed Oct  6 17:03:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 15:03:02 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>,
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>,
	<43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
Message-ID: <COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>


There is only one instance in the tree currently that I know of, and I write it relatively recently.
? (And I can workaround it easily by unnesting the function.)
Perhaps it was never seen before?

Here it is:


jbook2:src jay$ edit lego/ZChassisVBT.m3
jbook2:src jay$ pwd
/dev2/cm3/m3-ui/vbtkit/src


PROCEDURE NewBtn (uglyPosixText, win32ppm: TEXT; shadow: Shadow.T): VBT.T =

PROCEDURE Posix (t: TEXT; shadow: Shadow.T): VBT.T =
? BEGIN
??? WITH textVBT = TextVBT.New (t) DO
????? TextVBT.SetFont (textVBT, Font.BuiltIn, shadow);
????? RETURN NEW (ShadowedFeedbackVBT.T).init (textVBT, shadow)
??? END
? END Posix;

PROCEDURE Win32 (name: TEXT; shadow: Shadow.T): VBT.T =
? VAR
??? pm := VBTKitResources.GetPixmap (name);
??? pixvbt := NEW(PixmapVBT.T).init(pm, halign := 0.0, valign := 0.0,
??????????????????????????????? op := PaintOp.Copy);
? BEGIN
??? RETURN NEW (ShadowedFeedbackVBT.T).init (pixvbt, shadow)
? END Win32;

? BEGIN
??? CASE Compiler.ThisOS OF
????? | Compiler.OS.POSIX => RETURN Posix(uglyPosixText, shadow);
????? | Compiler.OS.WIN32 => RETURN Win32(win32ppm, shadow);
??? END;
? END NewBtn;

Of course, between Posix and Win32, one is dead.

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 10:34:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] compilation failure on Solaris
>
> I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated.
>
> Sent from my iPhone
>
> On Oct 6, 2010, at 9:24 AM, Jay K  wrote:
>
> > Plus the long time we used volatile.
> > Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
> > until relatively recently (nested functions that gcc thinks are unused, but are referenced
> > from the module data).
> >
> > - Jay
> >
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Wed, 6 Oct 2010 09:07:31 -0400
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] compilation failure on Solaris
> >>
> >> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
> >>
> >> On 6 Oct 2010, at 05:20, Jay K wrote:
> >>
> >>>
> >>> I see. It occurs even on a cross build.
> >>> It should be better now -- by avoiding certain large changes on this platform.
> >>> A C generating backend is getting ever more tempting..
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
> >>>> From: wagner at elegosoft.com
> >>>> To: m3devel at elegosoft.com
> >>>> Subject: [M3devel] compilation failure on Solaris
> >>>>
> >>>> There are segmentation faults during compilation of Lex.m3, see:
> >>>>
> >>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> >>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
> >>>>
> >>>> === package m3-libs/libm3 ===
> >>>> +++ cm3 -build
> >>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> >>>> +++
> >>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> >>>> Please submit a full bug report,
> >>>> with preprocessed source if appropriate.
> >>>> See for instructions.
> >>>> m3_backend => 4
> >>>> m3cc (aka cm3cg) failed compiling: Lex.mc
> >>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> >>>> Please submit a full bug report,
> >>>> with preprocessed source if appropriate.
> >>>> See for instructions.
> >>>> m3_backend => 4
> >>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
> >>>>
> >>>> Olaf
> >>>> --
> >>>> Olaf Wagner -- elego Software Solutions GmbH
> >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>>>
> >>>
> >>
> >
 		 	   		  

From dragisha at m3w.org  Wed Oct  6 18:49:54 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 06 Oct 2010 18:49:54 +0200
Subject: [M3devel] GCC version, danger zone
In-Reply-To: <COL101-W6126EB7972E7D5607EA24FE66E0@phx.gbl>
References: <20101006104543.A18DB2474003@birch.elegosoft.com>
	, , <D487B610-E139-4791-83C6-9B9824A34DD9@cs.purdue.edu>
	, <COL101-W63B0B6343EF7EBA88858AFE66E0@phx.gbl>
	, <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu>
	<COL101-W6126EB7972E7D5607EA24FE66E0@phx.gbl>
Message-ID: <1286383794.3849.5.camel@boromir.m3w.org>

GNU Pascal team capitulated on GCC backend, due to galloping changes GCC
team is making.
SRC people fixed SRCM3 on particular GCC release just because their
change rate is rampant.
Let's be careful to not go way of GNU Pascal -> way of dodo. Please!

On Wed, 2010-10-06 at 15:06 +0000, Jay K wrote:
> 
> Let me maybe get 4.5.1 working before -O3.
> Granted..I agree it was probably working as recently as the recent
> release.
> What changed since then? In the 4.3 tree? ==> I moved from 4.3.0 to
> 4.3.5.
> So if we want to find -O3 working, it is probably there.
> 
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Wed Oct  6 19:50:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 13:50:00 -0400
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>,
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>,
	<43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
	<COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>
Message-ID: <C1A1128F-9125-4499-896C-F63D22455DBC@cs.purdue.edu>

This code has been around a long time.


On 6 Oct 2010, at 11:03, Jay K wrote:

> 
> There is only one instance in the tree currently that I know of, and I write it relatively recently.
>   (And I can workaround it easily by unnesting the function.)
> Perhaps it was never seen before?
> 
> Here it is:
> 
> 
> jbook2:src jay$ edit lego/ZChassisVBT.m3
> jbook2:src jay$ pwd
> /dev2/cm3/m3-ui/vbtkit/src
> 
> 
> PROCEDURE NewBtn (uglyPosixText, win32ppm: TEXT; shadow: Shadow.T): VBT.T =
> 
> PROCEDURE Posix (t: TEXT; shadow: Shadow.T): VBT.T =
>   BEGIN
>     WITH textVBT = TextVBT.New (t) DO
>       TextVBT.SetFont (textVBT, Font.BuiltIn, shadow);
>       RETURN NEW (ShadowedFeedbackVBT.T).init (textVBT, shadow)
>     END
>   END Posix;
> 
> PROCEDURE Win32 (name: TEXT; shadow: Shadow.T): VBT.T =
>   VAR
>     pm := VBTKitResources.GetPixmap (name);
>     pixvbt := NEW(PixmapVBT.T).init(pm, halign := 0.0, valign := 0.0,
>                                 op := PaintOp.Copy);
>   BEGIN
>     RETURN NEW (ShadowedFeedbackVBT.T).init (pixvbt, shadow)
>   END Win32;
> 
>   BEGIN
>     CASE Compiler.ThisOS OF
>       | Compiler.OS.POSIX => RETURN Posix(uglyPosixText, shadow);
>       | Compiler.OS.WIN32 => RETURN Win32(win32ppm, shadow);
>     END;
>   END NewBtn;
> 
> Of course, between Posix and Win32, one is dead.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 6 Oct 2010 10:34:45 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] compilation failure on Solaris
>> 
>> I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated.
>> 
>> Sent from my iPhone
>> 
>> On Oct 6, 2010, at 9:24 AM, Jay K  wrote:
>> 
>>> Plus the long time we used volatile.
>>> Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
>>> until relatively recently (nested functions that gcc thinks are unused, but are referenced
>>> from the module data).
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 6 Oct 2010 09:07:31 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] compilation failure on Solaris
>>>> 
>>>> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
>>>> 
>>>> On 6 Oct 2010, at 05:20, Jay K wrote:
>>>> 
>>>>> 
>>>>> I see. It occurs even on a cross build.
>>>>> It should be better now -- by avoiding certain large changes on this platform.
>>>>> A C generating backend is getting ever more tempting..
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
>>>>>> From: wagner at elegosoft.com
>>>>>> To: m3devel at elegosoft.com
>>>>>> Subject: [M3devel] compilation failure on Solaris
>>>>>> 
>>>>>> There are segmentation faults during compilation of Lex.m3, see:
>>>>>> 
>>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
>>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>>>>>> 
>>>>>> === package m3-libs/libm3 ===
>>>>>> +++ cm3 -build
>>>>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
>>>>>> +++
>>>>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
>>>>>> Please submit a full bug report,
>>>>>> with preprocessed source if appropriate.
>>>>>> See for instructions.
>>>>>> m3_backend => 4
>>>>>> m3cc (aka cm3cg) failed compiling: Lex.mc
>>>>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
>>>>>> Please submit a full bug report,
>>>>>> with preprocessed source if appropriate.
>>>>>> See for instructions.
>>>>>> m3_backend => 4
>>>>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>>>>>> 
>>>>>> Olaf
>>>>>> --
>>>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>>>>> 
>>>>> 
>>>> 
>>> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed Oct  6 19:53:48 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 13:53:48 -0400
Subject: [M3devel] GCC version, danger zone
In-Reply-To: <1286383794.3849.5.camel@boromir.m3w.org>
References: <20101006104543.A18DB2474003@birch.elegosoft.com> , ,
	<D487B610-E139-4791-83C6-9B9824A34DD9@cs.purdue.edu> ,
	<COL101-W63B0B6343EF7EBA88858AFE66E0@phx.gbl> ,
	<074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu>
	<COL101-W6126EB7972E7D5607EA24FE66E0@phx.gbl>
	<1286383794.3849.5.camel@boromir.m3w.org>
Message-ID: <5D4465D1-C461-4739-A288-6EA6E94F966C@cs.purdue.edu>

Good point!

On 6 Oct 2010, at 12:49, Dragi?a Duri? wrote:

> GNU Pascal team capitulated on GCC backend, due to galloping changes GCC
> team is making.
> SRC people fixed SRCM3 on particular GCC release just because their
> change rate is rampant.
> Let's be careful to not go way of GNU Pascal -> way of dodo. Please!
> 
> On Wed, 2010-10-06 at 15:06 +0000, Jay K wrote:
>> 
>> Let me maybe get 4.5.1 working before -O3.
>> Granted..I agree it was probably working as recently as the recent
>> release.
>> What changed since then? In the 4.3 tree? ==> I moved from 4.3.0 to
>> 4.3.5.
>> So if we want to find -O3 working, it is probably there.
>> 
>> 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>



From dragisha at m3w.org  Wed Oct  6 22:40:12 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 06 Oct 2010 22:40:12 +0200
Subject: [M3devel] static linking of some C libs...
Message-ID: <1286397612.7401.0.camel@boromir.m3w.org>

I would like to statically link only some C libs. How to do it?
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu Oct  7 00:37:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 22:37:35 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <C1A1128F-9125-4499-896C-F63D22455DBC@cs.purdue.edu>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>,
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>,
	<43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
	<COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>,
	<C1A1128F-9125-4499-896C-F63D22455DBC@cs.purdue.edu>
Message-ID: <COL101-W266E6E413DA34C43D955B2E66E0@phx.gbl>


The construct that leads the backend when compiling "unit at a time" to throw out referenced nested function dates to only May 2010.

http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/ZChassisVBT.m3

?- Jay


----------------------------------------
> Subject: Re: [M3devel] compilation failure on Solaris
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 13:50:00 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> This code has been around a long time.
>
>
> On 6 Oct 2010, at 11:03, Jay K wrote:
>
> >
> > There is only one instance in the tree currently that I know of, and I write it relatively recently.
> > (And I can workaround it easily by unnesting the function.)
> > Perhaps it was never seen before?
> >
> > Here it is:
> >
> >
> > jbook2:src jay$ edit lego/ZChassisVBT.m3
> > jbook2:src jay$ pwd
> > /dev2/cm3/m3-ui/vbtkit/src
> >
> >
> > PROCEDURE NewBtn (uglyPosixText, win32ppm: TEXT; shadow: Shadow.T): VBT.T =
> >
> > PROCEDURE Posix (t: TEXT; shadow: Shadow.T): VBT.T =
> > BEGIN
> > WITH textVBT = TextVBT.New (t) DO
> > TextVBT.SetFont (textVBT, Font.BuiltIn, shadow);
> > RETURN NEW (ShadowedFeedbackVBT.T).init (textVBT, shadow)
> > END
> > END Posix;
> >
> > PROCEDURE Win32 (name: TEXT; shadow: Shadow.T): VBT.T =
> > VAR
> > pm := VBTKitResources.GetPixmap (name);
> > pixvbt := NEW(PixmapVBT.T).init(pm, halign := 0.0, valign := 0.0,
> > op := PaintOp.Copy);
> > BEGIN
> > RETURN NEW (ShadowedFeedbackVBT.T).init (pixvbt, shadow)
> > END Win32;
> >
> > BEGIN
> > CASE Compiler.ThisOS OF
> > | Compiler.OS.POSIX => RETURN Posix(uglyPosixText, shadow);
> > | Compiler.OS.WIN32 => RETURN Win32(win32ppm, shadow);
> > END;
> > END NewBtn;
> >
> > Of course, between Posix and Win32, one is dead.
> >
> > - Jay
> >
> >
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Wed, 6 Oct 2010 10:34:45 -0400
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] compilation failure on Solaris
> >>
> >> I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated.
> >>
> >> Sent from my iPhone
> >>
> >> On Oct 6, 2010, at 9:24 AM, Jay K wrote:
> >>
> >>> Plus the long time we used volatile.
> >>> Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
> >>> until relatively recently (nested functions that gcc thinks are unused, but are referenced
> >>> from the module data).
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> From: hosking at cs.purdue.edu
> >>>> Date: Wed, 6 Oct 2010 09:07:31 -0400
> >>>> To: jay.krell at cornell.edu
> >>>> CC: m3devel at elegosoft.com
> >>>> Subject: Re: [M3devel] compilation failure on Solaris
> >>>>
> >>>> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
> >>>>
> >>>> On 6 Oct 2010, at 05:20, Jay K wrote:
> >>>>
> >>>>>
> >>>>> I see. It occurs even on a cross build.
> >>>>> It should be better now -- by avoiding certain large changes on this platform.
> >>>>> A C generating backend is getting ever more tempting..
> >>>>>
> >>>>> - Jay
> >>>>>
> >>>>> ----------------------------------------
> >>>>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
> >>>>>> From: wagner at elegosoft.com
> >>>>>> To: m3devel at elegosoft.com
> >>>>>> Subject: [M3devel] compilation failure on Solaris
> >>>>>>
> >>>>>> There are segmentation faults during compilation of Lex.m3, see:
> >>>>>>
> >>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> >>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
> >>>>>>
> >>>>>> === package m3-libs/libm3 ===
> >>>>>> +++ cm3 -build
> >>>>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> >>>>>> +++
> >>>>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> >>>>>> Please submit a full bug report,
> >>>>>> with preprocessed source if appropriate.
> >>>>>> See for instructions.
> >>>>>> m3_backend => 4
> >>>>>> m3cc (aka cm3cg) failed compiling: Lex.mc
> >>>>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> >>>>>> Please submit a full bug report,
> >>>>>> with preprocessed source if appropriate.
> >>>>>> See for instructions.
> >>>>>> m3_backend => 4
> >>>>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
> >>>>>>
> >>>>>> Olaf
> >>>>>> --
> >>>>>> Olaf Wagner -- elego Software Solutions GmbH
> >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 00:52:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 22:52:22 +0000
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <1286397612.7401.0.camel@boromir.m3w.org>
References: <1286397612.7401.0.camel@boromir.m3w.org>
Message-ID: <COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>


I don't have a good answer here.
I have some bad ones: Only have static libraries.
We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.


Microsoft link doesn't really have the notion you ask for. It just has libraries.
It has a better model imho.
It never links to .so/.dll files.
It links to .libs.
Those .libs might be "normal" static ones with real code in them,
or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
(In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
.libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
once you know to look.)


The Unix linkers have a wierd model where they probe around like mad and are willing
to "link" to an .so/.dll file with no .lib/.a in sight.
It is good in terms of "self description" but bad in terms of conflating runtime and tools.


In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
is the norm.


The import libraries are to a large extent a small transform of the .dll files, so, well,
there is something to the Unix model. It isn't completely crazy, it seems better at first
maybe but it is wierd and inferior ultimately.


So, for Windows, which I suspect you are talking about, point the linker at a static library.
The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
environment variable, or the -libpath command line option. But it doesn't make its own
static vs. dynamic decisions or probe around in a way to do so, except to the extent
that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
full paths to .lib files, what you ask for is what you get.


(I do suspect you are asking specifically about Windows.)


Modula-3 does something slightly tricky in order to allow static and dynamic and
for it to later chose. It makes static libraries for everything: foo.lib.sa.
"sa" = standalone.
And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
If it is build_standalone, it renames foo.lib.sa to foo.lib.


Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.


All this is done by cm3/the config file though. No trickery or probing in the linker.


It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
And how there is m3core.dll, but no m3quake.dll.


I does basically identical for Unix even.
Part of the Unix story is using -fPIC always.
It is an inefficiency sometimes, but imho worth it.
I wish Windows code was always position independent, rather than worry
about base addresses and relocation costs (prior to Vista, relocs were
applied to entire .dll at load, killing demand paging and page sharing;
as of Vista, they are applied at page-in, which preserves demand paging
but still loses on page sharing).


?-Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Wed, 6 Oct 2010 22:40:12 +0200
> Subject: [M3devel] static linking of some C libs...
>
> I would like to statically link only some C libs. How to do it?
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 01:20:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 23:20:12 +0000
Subject: [M3devel] gcc 4.5 + AMD64_SOLARIS fyi
Message-ID: <COL101-W18C65A5BA10B392652EBDFE66E0@phx.gbl>


m3cc (aka cm3cg) failed compiling: Unicode.mc
new source -> compiling Address.i3
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated


occurs in pretty much every file

?- Jay
 		 	   		  

From dragisha at m3w.org  Thu Oct  7 07:58:55 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 07 Oct 2010 07:58:55 +0200
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>
References: <1286397612.7401.0.camel@boromir.m3w.org>
	<COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>
Message-ID: <1286431135.7401.13.camel@boromir.m3w.org>

gcc GSTABS_TO_WARN_COMMON_LD_ARGS -Wl,-rpath,/usr/local/cm3/bin/../lib  -o MYPGM  _m3main.o MYOBJS /usr/local/cm3/pkg/openssl/AMD64_LINUX/libhm3openssl.a /usr/lib64/libssl.a /usr/lib64/libcrypto.a -lz -L/usr/local/cm3/pkg/libm3/AMD64_LINUX -lm3 -L/usr/local/cm3/pkg/m3core/AMD64_LINUX -lm3core -lm -ldl -lkrb5 -pthread

This is what I made.... Manually of course.
      * build_standalone() in m3makefile ;
      * cm3 -commands (this fails at linking because it cannot succeed
        if fully static, but I get original linking command I edit
        later)
      * cd ../AMD64_LINUX
      * command from first line...

build_standalone() is just setting build_shared somewhere in Builder.m3
to FALSE.. So it's all or nothing. What we need is a way to specify
(best would be in main app m3makefile, so installed libraries can be
static on demand) what libraries we need static. With that info passed
through m3makefile, current quake code can produce custom command.

If nobody has time/will to do this, I'll do it after I deliver my
current project.

On Wed, 2010-10-06 at 22:52 +0000, Jay K wrote:
> I don't have a good answer here.
> I have some bad ones: Only have static libraries.
> We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.
> 
> 
> Microsoft link doesn't really have the notion you ask for. It just has libraries.
> It has a better model imho.
> It never links to .so/.dll files.
> It links to .libs.
> Those .libs might be "normal" static ones with real code in them,
> or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
> (In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
> .libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
> It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
> However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
> once you know to look.)
> 
> 
> The Unix linkers have a wierd model where they probe around like mad and are willing
> to "link" to an .so/.dll file with no .lib/.a in sight.
> It is good in terms of "self description" but bad in terms of conflating runtime and tools.
> 
> 
> In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
> is the norm.
> 
> 
> The import libraries are to a large extent a small transform of the .dll files, so, well,
> there is something to the Unix model. It isn't completely crazy, it seems better at first
> maybe but it is wierd and inferior ultimately.
> 
> 
> So, for Windows, which I suspect you are talking about, point the linker at a static library.
> The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
> environment variable, or the -libpath command line option. But it doesn't make its own
> static vs. dynamic decisions or probe around in a way to do so, except to the extent
> that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
> full paths to .lib files, what you ask for is what you get.
> 
> 
> (I do suspect you are asking specifically about Windows.)
> 
> 
> Modula-3 does something slightly tricky in order to allow static and dynamic and
> for it to later chose. It makes static libraries for everything: foo.lib.sa.
> "sa" = standalone.
> And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
> If it is build_standalone, it renames foo.lib.sa to foo.lib.
> 
> 
> Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
> If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.
> 
> 
> All this is done by cm3/the config file though. No trickery or probing in the linker.
> 
> 
> It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
> And how there is m3core.dll, but no m3quake.dll.
> 
> 
> I does basically identical for Unix even.
> Part of the Unix story is using -fPIC always.
> It is an inefficiency sometimes, but imho worth it.
> I wish Windows code was always position independent, rather than worry
> about base addresses and relocation costs (prior to Vista, relocs were
> applied to entire .dll at load, killing demand paging and page sharing;
> as of Vista, they are applied at page-in, which preserves demand paging
> but still loses on page sharing).
> 
> 
>  -Jay
> 
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: m3devel at elegosoft.com
> > Date: Wed, 6 Oct 2010 22:40:12 +0200
> > Subject: [M3devel] static linking of some C libs...
> >
> > I would like to statically link only some C libs. How to do it?
> > --
> > Dragi?a Duri? 
> >
>  		 	   		  

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu Oct  7 08:13:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 06:13:54 +0000
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <1286431135.7401.13.camel@boromir.m3w.org>
References: <1286397612.7401.0.camel@boromir.m3w.org>,
	<COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>,
	<1286431135.7401.13.camel@boromir.m3w.org>
Message-ID: <COL101-W5E9607FC46DFC67A99F8EE66F0@phx.gbl>


Right.
What you want something like:
import_standalone("libfoo")
or import_static("libfoo")

shouldn't be too hard.
Just stick libfoo in some global hashtable and then when linking looks for libfoo.so vs. libfoo.a, it can use that to guide.

That is assuming libfoo is built by Modula-3 and that there are both.
If it is a C library, you'll have to do something else.

<rant>
I find Unix link command lines extremely confusing and very likely both
? having too many and too few features. What with options being in effect
until end of command line, or maybe not, or being able to turn them off/on as you go,
making it all ridiculously order-dependent. You really want to "attach" options to parameters,
or just have a dramatically simpler model and fewer options.
With Windows it is very simple. You give it a full path to a .lib or a leaf path and %LIB% is searched.
There are no options that apply to some or all .libs. It is much much much simpler, and provides
all that you need/want.
All the more reason, perhaps, to write our linker in Modula-3!
? (That'd be a great piece of a cross build story...but is a ton ton ton of work.)
Unix linkers also have a ridiculous number of confusing options like -z origin (why?), -z now (the
default on Windows, unless you use -delayload), -z combreloc, etc. etc. etc. including man pages
that list options that aren't really there because the loader doesn't support them (.e.g -z origin
historically on NetBSD).

Not to mention the historical defaults that were obviously wrong at the time and now have all been since deprecated.
? e.g. the flat namespace, leading to more confusing an inefficiency. As if emulating static linking
? was of such paramount importance that everything could be made worse in support of this misguided direction...
</rant>


?- Jay


----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 7 Oct 2010 07:58:55 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] static linking of some C libs...
>
> gcc GSTABS_TO_WARN_COMMON_LD_ARGS -Wl,-rpath,/usr/local/cm3/bin/../lib -o MYPGM _m3main.o MYOBJS /usr/local/cm3/pkg/openssl/AMD64_LINUX/libhm3openssl.a /usr/lib64/libssl.a /usr/lib64/libcrypto.a -lz -L/usr/local/cm3/pkg/libm3/AMD64_LINUX -lm3 -L/usr/local/cm3/pkg/m3core/AMD64_LINUX -lm3core -lm -ldl -lkrb5 -pthread
>
> This is what I made.... Manually of course.
> * build_standalone() in m3makefile ;
> * cm3 -commands (this fails at linking because it cannot succeed
> if fully static, but I get original linking command I edit
> later)
> * cd ../AMD64_LINUX
> * command from first line...
>
> build_standalone() is just setting build_shared somewhere in Builder.m3
> to FALSE.. So it's all or nothing. What we need is a way to specify
> (best would be in main app m3makefile, so installed libraries can be
> static on demand) what libraries we need static. With that info passed
> through m3makefile, current quake code can produce custom command.
>
> If nobody has time/will to do this, I'll do it after I deliver my
> current project.
>
> On Wed, 2010-10-06 at 22:52 +0000, Jay K wrote:
> > I don't have a good answer here.
> > I have some bad ones: Only have static libraries.
> > We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.
> >
> >
> > Microsoft link doesn't really have the notion you ask for. It just has libraries.
> > It has a better model imho.
> > It never links to .so/.dll files.
> > It links to .libs.
> > Those .libs might be "normal" static ones with real code in them,
> > or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
> > (In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
> > .libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
> > It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
> > However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
> > once you know to look.)
> >
> >
> > The Unix linkers have a wierd model where they probe around like mad and are willing
> > to "link" to an .so/.dll file with no .lib/.a in sight.
> > It is good in terms of "self description" but bad in terms of conflating runtime and tools.
> >
> >
> > In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
> > is the norm.
> >
> >
> > The import libraries are to a large extent a small transform of the .dll files, so, well,
> > there is something to the Unix model. It isn't completely crazy, it seems better at first
> > maybe but it is wierd and inferior ultimately.
> >
> >
> > So, for Windows, which I suspect you are talking about, point the linker at a static library.
> > The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
> > environment variable, or the -libpath command line option. But it doesn't make its own
> > static vs. dynamic decisions or probe around in a way to do so, except to the extent
> > that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
> > full paths to .lib files, what you ask for is what you get.
> >
> >
> > (I do suspect you are asking specifically about Windows.)
> >
> >
> > Modula-3 does something slightly tricky in order to allow static and dynamic and
> > for it to later chose. It makes static libraries for everything: foo.lib.sa.
> > "sa" = standalone.
> > And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
> > If it is build_standalone, it renames foo.lib.sa to foo.lib.
> >
> >
> > Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
> > If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.
> >
> >
> > All this is done by cm3/the config file though. No trickery or probing in the linker.
> >
> >
> > It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
> > And how there is m3core.dll, but no m3quake.dll.
> >
> >
> > I does basically identical for Unix even.
> > Part of the Unix story is using -fPIC always.
> > It is an inefficiency sometimes, but imho worth it.
> > I wish Windows code was always position independent, rather than worry
> > about base addresses and relocation costs (prior to Vista, relocs were
> > applied to entire .dll at load, killing demand paging and page sharing;
> > as of Vista, they are applied at page-in, which preserves demand paging
> > but still loses on page sharing).
> >
> >
> > -Jay
> >
> > ----------------------------------------
> > > From: dragisha at m3w.org
> > > To: m3devel at elegosoft.com
> > > Date: Wed, 6 Oct 2010 22:40:12 +0200
> > > Subject: [M3devel] static linking of some C libs...
> > >
> > > I would like to statically link only some C libs. How to do it?
> > > --
> > > Dragi?a Duri?
> > >
> >
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 08:21:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 06:21:14 +0000
Subject: [M3devel] gcc 4.5 + AMD64_SOLARIS fyi
In-Reply-To: <COL101-W18C65A5BA10B392652EBDFE66E0@phx.gbl>
References: <COL101-W18C65A5BA10B392652EBDFE66E0@phx.gbl>
Message-ID: <COL101-W48F1E07E8067647F7D42A7E66F0@phx.gbl>


Stupid autoconf just breaks things.

??? gcc_GAS_CHECK_FEATURE([.quad directive],
????? gcc_cv_as_ix86_quad,,,
????? [.quad 0],,
????? [AC_DEFINE(HAVE_AS_IX86_QUAD, 1,
??????? [Define if your assembler supports the .quad directive.])])

added in gcc 4.5 breaks things nicely.
Fix will be to just hardcode  gcc_cv_as_ix86_quad as true in src/m3makefile when doing cross builds to AMD64_SOLARIS.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: gcc 4.5 + AMD64_SOLARIS fyi
> Date: Wed, 6 Oct 2010 23:20:12 +0000
>
>
> m3cc (aka cm3cg) failed compiling: Unicode.mc
> new source -> compiling Address.i3
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
>
>
> occurs in pretty much every file
>
>  - Jay
>
 		 	   		  

From dragisha at m3w.org  Thu Oct  7 09:16:36 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 07 Oct 2010 09:16:36 +0200
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <COL101-W5E9607FC46DFC67A99F8EE66F0@phx.gbl>
References: <1286397612.7401.0.camel@boromir.m3w.org>
	,<COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>
	,<1286431135.7401.13.camel@boromir.m3w.org>
	<COL101-W5E9607FC46DFC67A99F8EE66F0@phx.gbl>
Message-ID: <1286435796.7401.21.camel@boromir.m3w.org>

Of course it's built with Modula-3, and if it's pure C lib - then make a
"placeholder" Modula-3 lib just to keep it "under quake". That way we
will have full control on options, resolving,,, per platform where
differences occur. As opposed to autocrap way and m4 (it's not Modula-4,
don't jump :).

GCC is a hell, and linking "logic" is just a tip of the iceberg. Order
dependency is least of problems. Thus said - I am against Modula-3
linker - our resources are too scarce to fix everything.

import_standalone() would fill static_libs hash, just like import fills
imported_libs, and build_standalone() will just move everything from
imported_libs to static_libs before m3_link continues. Looks clean.

On Thu, 2010-10-07 at 06:13 +0000, Jay K wrote:
> 
> Right.
> What you want something like:
> import_standalone("libfoo")
> or import_static("libfoo")
> 
> shouldn't be too hard.
> Just stick libfoo in some global hashtable and then when linking looks
> for libfoo.so vs. libfoo.a, it can use that to guide.
> 
> That is assuming libfoo is built by Modula-3 and that there are both.
> If it is a C library, you'll have to do something else.
> 
> <rant>
> I find Unix link command lines extremely confusing and very likely
> both
>   having too many and too few features. What with options being in
> effect
> until end of command line, or maybe not, or being able to turn them
> off/on as you go,
> making it all ridiculously order-dependent. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu Oct  7 10:15:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 08:15:39 +0000
Subject: [M3devel] static chain: what does D do?
In-Reply-To: <COL101-W40B78A4BD59FE234DD80F6E66E0@phx.gbl>
References: <20101006090354.BD40E2474003@birch.elegosoft.com>, ,
	<2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu>,
	<COL101-W54E93A9A943E33E99177CCE66E0@phx.gbl>,
	<4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu>,
	<COL101-W40B78A4BD59FE234DD80F6E66E0@phx.gbl>
Message-ID: <COL101-W8344853307806904E5F6AE66F0@phx.gbl>



> > Hmm. Do we know what Pascal/Ada/D and friends do in this instance?
>
>
> Good point. I don't know.

Here is part of the answer:

jbook2:d jay$ grep -i chain p* | grep DEF
patch-apple-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_EXPR, "static_chain_expr", tcc_expression, 1)
patch-apple-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_DECL, "static_chain_decl", tcc_expression, 0)
patch-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_EXPR, "static_chain_expr", tcc_expression, 1)
patch-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_DECL, "static_chain_decl", tcc_expression, 0)
patch-gcc-4.1.x:+ DEFTREECODE (STATIC_CHAIN_EXPR, "static_chain_expr", tcc_expression, 1)
patch-gcc-4.1.x:+ DEFTREECODE (STATIC_CHAIN_DECL, "static_chain_decl", tcc_expression, 0)


interesting.
We had one tree code. They add two.
Their changes are more involved than ours.

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 11:45:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 09:45:49 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
Message-ID: <COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>


Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
I suspect we are underusing volatile.
e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
? The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.

I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
all MODIFY_EXPR. There is probably redundancy here.

Notice that even the original volatization was incomplete.
It volatized current function's current temporaries/locals, but not others declared after
any call to setjmp. I fixed that at some point.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: random notes: gcc 4.5, sparc, etc.
> Date: Wed, 6 Oct 2010 13:30:00 +0000
>
>
> some random notes
>
> Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
>   Easy test is to run cm3 without a neighboring cm3.cfg and the error
>   is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
>
> Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
>   Same easy test, but it crashes upon first attempt to raise an exception.
>
> Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
>   NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
>
> Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
>   Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
>
> Meanwhile I think many other targets are working ok with 4.5.
> Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
>
>  - Jay
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 13:22:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 11:22:28 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>,
	<COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>
Message-ID: <COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>


oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Thu, 7 Oct 2010 09:45:49 +0000
>
>
> Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> I suspect we are underusing volatile.
> e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
>   The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
>
> I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> all MODIFY_EXPR. There is probably redundancy here.
>
> Notice that even the original volatization was incomplete.
> It volatized current function's current temporaries/locals, but not others declared after
> any call to setjmp. I fixed that at some point.
>
>  - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: random notes: gcc 4.5, sparc, etc.
> > Date: Wed, 6 Oct 2010 13:30:00 +0000
> >
> >
> > some random notes
> >
> > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> >
> > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > Same easy test, but it crashes upon first attempt to raise an exception.
> >
> > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> >
> > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> >
> > Meanwhile I think many other targets are working ok with 4.5.
> > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> >
> > - Jay
> >
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 22:02:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 20:02:11 +0000
Subject: [M3devel] Solaris/amd64
Message-ID: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>


There's a complete Solaris/amd64 in /home/jkrell/cm3.amd64 on the opencsw machines having used 4.5.1 backend.
? I can't test the X apps I think (not sure of the remoting).
Would be good to get that in Hudson.

?- Jay


 		 	   		  

From wagner at elegosoft.com  Fri Oct  8 10:28:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 08 Oct 2010 10:28:24 +0200
Subject: [M3devel] Solaris/amd64
In-Reply-To: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
References: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
Message-ID: <20101008102824.61nbtaufk8gowk4s@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> There's a complete Solaris/amd64 in /home/jkrell/cm3.amd64 on the   
> opencsw machines having used 4.5.1 backend.
> ? I can't test the X apps I think (not sure of the remoting).
> Would be good to get that in Hudson.

Is anybody else interested in setting up those jobs? Should not be
difficult, mostly a matter of copy&paste in HTML forms and doing
some one-time bootstrapping to create the necessary directories
and CM3 installations.

It would be great if others acquire some experience with our Hudson
build and regression tests.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Oct  8 13:44:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 11:44:57 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>,
	<COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>,
	<COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>
Message-ID: <COL101-W53AFBBF14A6AC6EA7745F2E6500@phx.gbl>


For the record:
Still, no luck. Replacing MxConfig.ms from 4.3 seems to let it get further.
Or maybe it was M*.
Problem seems to be that when M3File__IsReadable returns, $l7 gets zeroed.

But I'm going to try another hack.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Thu, 7 Oct 2010 11:22:28 +0000
>
>
> oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.
>
>  - Jay
>
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > Date: Thu, 7 Oct 2010 09:45:49 +0000
> >
> >
> > Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> > I suspect we are underusing volatile.
> > e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
> > The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
> >
> > I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> > all MODIFY_EXPR. There is probably redundancy here.
> >
> > Notice that even the original volatization was incomplete.
> > It volatized current function's current temporaries/locals, but not others declared after
> > any call to setjmp. I fixed that at some point.
> >
> > - Jay
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Subject: random notes: gcc 4.5, sparc, etc.
> > > Date: Wed, 6 Oct 2010 13:30:00 +0000
> > >
> > >
> > > some random notes
> > >
> > > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> > >
> > > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > > Same easy test, but it crashes upon first attempt to raise an exception.
> > >
> > > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> > >
> > > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> > >
> > > Meanwhile I think many other targets are working ok with 4.5.
> > > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> > >
> > > - Jay
> > >
> >
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  8 16:17:00 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 08 Oct 2010 16:17:00 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286285550.3514.20.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>
Message-ID: <1286547420.7401.43.camel@boromir.m3w.org>

WindowStar is 
TYPE
  Window = RECORD
    user_data: void_star
  END;
  WindowStar = UNTRACED REF Window;

and this whole record is
typedef struct {
  GdkEventType type;
  GdkWindow *window;
  gint8 send_event;
  guint32 time;
  guint state;
  guint keyval;
  gint length;
  gchar *string;
  guint16 hardware_keycode;
  guint8 group;
  guint is_modifier : 1;
} GdkEventKey;

in C.

It's Modula-3 BYTESIZE is 64, and C sizeof() is 56. window field is aligned at 8 bytes (thank you Jay for m3gap 8_56!) and C's GdkWindow * is aligned at 4 bytes.

As I don't use window field I'll split it in two placeholder int's, but this is, IMO, interesting point.

dd

On Tue, 2010-10-05 at 15:32 +0200, Dragi?a Duri? wrote:
>   EventKey = RECORD 
>     type: EventType;
>     window: WindowStar;
>     send_event: char;
>     time: unsigned_long_int;  
>     state: unsigned_int;
>     keyval: unsigned_int;
>     length: int;
>     string: char_star;
>     hardware_keycode: unsigned_short_int;
>     group: unsigned_char;
>   END;
> 
> also with m3gdb....
> 
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x0,
> send_event = 0 '\000', 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  8 20:36:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 18:36:44 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286547420.7401.43.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>,
	<1286547420.7401.43.camel@boromir.m3w.org>
Message-ID: <COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>


I may have broken this, a while ago. I may have relaxed all the alignments long ago.
We have very little interfacing with C now and most of that is with our own C,
where I avoid small types.
We have had at least temporary problems related to our rules being sort of too strict.
? The need for -munaligned-double or such. (which reminds me I should try that again).
? Where our rules were ok but gcc's default for to align stuff more.
? Where our layout and gcc's didn't agree.

How bad would it be to generate or write a C layer that copies stuff into "idealized" structs?
? Where the types are all INTEGER or LONGINT or pointers.

?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Fri, 8 Oct 2010 16:17:00 +0200
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> WindowStar is
> TYPE
> Window = RECORD
> user_data: void_star
> END;
> WindowStar = UNTRACED REF Window;
>
> and this whole record is
> typedef struct {
> GdkEventType type;
> GdkWindow *window;
> gint8 send_event;
> guint32 time;
> guint state;
> guint keyval;
> gint length;
> gchar *string;
> guint16 hardware_keycode;
> guint8 group;
> guint is_modifier : 1;
> } GdkEventKey;
>
> in C.
>
> It's Modula-3 BYTESIZE is 64, and C sizeof() is 56. window field is aligned at 8 bytes (thank you Jay for m3gap 8_56!) and C's GdkWindow * is aligned at 4 bytes.
>
> As I don't use window field I'll split it in two placeholder int's, but this is, IMO, interesting point.
>
> dd
>
> On Tue, 2010-10-05 at 15:32 +0200, Dragi?a Duri? wrote:
> > EventKey = RECORD
> > type: EventType;
> > window: WindowStar;
> > send_event: char;
> > time: unsigned_long_int;
> > state: unsigned_int;
> > keyval: unsigned_int;
> > length: int;
> > string: char_star;
> > hardware_keycode: unsigned_short_int;
> > group: unsigned_char;
> > END;
> >
> > also with m3gdb....
> >
> > (m3gdb) p event
> > $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> > send_event = 0 '\000',
> --
> Dragi?a Duri? 
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  8 20:46:56 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 08 Oct 2010 20:46:56 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,<1286547420.7401.43.camel@boromir.m3w.org>
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
Message-ID: <1286563617.7401.68.camel@boromir.m3w.org>

We will always have some friction there... IMO, stricter is better, with
maybe a pragma there... preceding variable/field name, fixing align,
like

  EventKey = RECORD
    type: EventType;
    <* ALIGN 4 *> window: WindowStar;
    ...
  END;

As for GCC... Does it not make alignment exception, or something, to
reference non-aligned pointer on AMD64?

Idealized structs... I didn't follow you there, probably I missed
something earlier on list.

On Fri, 2010-10-08 at 18:36 +0000, Jay K wrote:
> I may have broken this, a while ago. I may have relaxed all the
> alignments long ago.
> We have very little interfacing with C now and most of that is with
> our own C,
> where I avoid small types.
> We have had at least temporary problems related to our rules being
> sort of too strict.
>   The need for -munaligned-double or such. (which reminds me I should
> try that again).
>   Where our rules were ok but gcc's default for to align stuff more.
>   Where our layout and gcc's didn't agree.
> 
> How bad would it be to generate or write a C layer that copies stuff
> into "idealized" structs?
>   Where the types are all INTEGER or LONGINT or pointers. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  8 21:00:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 19:00:14 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286563617.7401.68.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, ,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>,
	<1286563617.7401.68.camel@boromir.m3w.org>
Message-ID: <COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>


Idealized is you grow everything to LONGINT or INTEGER and sort by size,
and copy back/forth with C. There will be no padding, guaranteed.

?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 8 Oct 2010 20:46:56 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> We will always have some friction there... IMO, stricter is better, with
> maybe a pragma there... preceding variable/field name, fixing align,
> like
>
> EventKey = RECORD
> type: EventType;
> <* ALIGN 4 *> window: WindowStar;
> ...
> END;
>
> As for GCC... Does it not make alignment exception, or something, to
> reference non-aligned pointer on AMD64?
>
> Idealized structs... I didn't follow you there, probably I missed
> something earlier on list.
>
> On Fri, 2010-10-08 at 18:36 +0000, Jay K wrote:
> > I may have broken this, a while ago. I may have relaxed all the
> > alignments long ago.
> > We have very little interfacing with C now and most of that is with
> > our own C,
> > where I avoid small types.
> > We have had at least temporary problems related to our rules being
> > sort of too strict.
> > The need for -munaligned-double or such. (which reminds me I should
> > try that again).
> > Where our rules were ok but gcc's default for to align stuff more.
> > Where our layout and gcc's didn't agree.
> >
> > How bad would it be to generate or write a C layer that copies stuff
> > into "idealized" structs?
> > Where the types are all INTEGER or LONGINT or pointers.
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Fri Oct  8 21:01:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 19:01:09 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
Message-ID: <COL101-W339845E597D706AF5EEE09E6500@phx.gbl>


Or make all field references be via function calls to C.
Very good option imho.
Like how I access DIR->d_name.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org; m3devel at elegosoft.com
> Subject: RE: [M3devel] m3gap.... it's an alignment issue
> Date: Fri, 8 Oct 2010 18:36:44 +0000
>
>
> I may have broken this, a while ago. I may have relaxed all the alignments long ago.
> We have very little interfacing with C now and most of that is with our own C,
> where I avoid small types.
> We have had at least temporary problems related to our rules being sort of too strict.
>   The need for -munaligned-double or such. (which reminds me I should try that again).
>   Where our rules were ok but gcc's default for to align stuff more.
>   Where our layout and gcc's didn't agree.
>
> How bad would it be to generate or write a C layer that copies stuff into "idealized" structs?
>   Where the types are all INTEGER or LONGINT or pointers.
>
>  - Jay
>
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: m3devel at elegosoft.com
> > Date: Fri, 8 Oct 2010 16:17:00 +0200
> > Subject: Re: [M3devel] m3gap.... it's an alignment issue
> >
> > WindowStar is
> > TYPE
> > Window = RECORD
> > user_data: void_star
> > END;
> > WindowStar = UNTRACED REF Window;
> >
> > and this whole record is
> > typedef struct {
> > GdkEventType type;
> > GdkWindow *window;
> > gint8 send_event;
> > guint32 time;
> > guint state;
> > guint keyval;
> > gint length;
> > gchar *string;
> > guint16 hardware_keycode;
> > guint8 group;
> > guint is_modifier : 1;
> > } GdkEventKey;
> >
> > in C.
> >
> > It's Modula-3 BYTESIZE is 64, and C sizeof() is 56. window field is aligned at 8 bytes (thank you Jay for m3gap 8_56!) and C's GdkWindow * is aligned at 4 bytes.
> >
> > As I don't use window field I'll split it in two placeholder int's, but this is, IMO, interesting point.
> >
> > dd
> >
> > On Tue, 2010-10-05 at 15:32 +0200, Dragi?a Duri? wrote:
> > > EventKey = RECORD
> > > type: EventType;
> > > window: WindowStar;
> > > send_event: char;
> > > time: unsigned_long_int;
> > > state: unsigned_int;
> > > keyval: unsigned_int;
> > > length: int;
> > > string: char_star;
> > > hardware_keycode: unsigned_short_int;
> > > group: unsigned_char;
> > > END;
> > >
> > > also with m3gdb....
> > >
> > > (m3gdb) p event
> > > $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> > > send_event = 0 '\000',
> > --
> > Dragi?a Duri?
> >
>
 		 	   		  

From jay.krell at cornell.edu  Fri Oct  8 21:03:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 19:03:19 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286563617.7401.68.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, ,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>,
	<1286563617.7401.68.camel@boromir.m3w.org>
Message-ID: <COL101-W63F9F601EF463A07A12CE1E6500@phx.gbl>


Gcc does nothing special. There are "never" alignment exceptions on x86.
? Things might run slower. There is a control bit in the processor to make
? it more strict but surely nobody sets it.
? Some interlocked and maybe sse/sse2/3/4 intructions have alignment requirements.
?We either have to go pains to match it precisely, and have silent memory
? corruption if we fail. Or give up and don't really try.
By relaxed I meant larger alignments. You might call this more strict.

?- Jay


----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 8 Oct 2010 20:46:56 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> We will always have some friction there... IMO, stricter is better, with
> maybe a pragma there... preceding variable/field name, fixing align,
> like
>
> EventKey = RECORD
> type: EventType;
> <* ALIGN 4 *> window: WindowStar;
> ...
> END;
>
> As for GCC... Does it not make alignment exception, or something, to
> reference non-aligned pointer on AMD64?
>
> Idealized structs... I didn't follow you there, probably I missed
> something earlier on list.
>
> On Fri, 2010-10-08 at 18:36 +0000, Jay K wrote:
> > I may have broken this, a while ago. I may have relaxed all the
> > alignments long ago.
> > We have very little interfacing with C now and most of that is with
> > our own C,
> > where I avoid small types.
> > We have had at least temporary problems related to our rules being
> > sort of too strict.
> > The need for -munaligned-double or such. (which reminds me I should
> > try that again).
> > Where our rules were ok but gcc's default for to align stuff more.
> > Where our layout and gcc's didn't agree.
> >
> > How bad would it be to generate or write a C layer that copies stuff
> > into "idealized" structs?
> > Where the types are all INTEGER or LONGINT or pointers.
> --
> Dragi?a Duri? 
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  8 21:06:37 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 08 Oct 2010 21:06:37 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W339845E597D706AF5EEE09E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,<1286547420.7401.43.camel@boromir.m3w.org>
	,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	<COL101-W339845E597D706AF5EEE09E6500@phx.gbl>
Message-ID: <1286564797.7401.70.camel@boromir.m3w.org>

Not a bad idea, if we are generating wrapper code... To write all that
by hand... I am shuddering at thought :)

On Fri, 2010-10-08 at 19:01 +0000, Jay K wrote:
> 
> Or make all field references be via function calls to C.
> Very good option imho.
> Like how I access DIR->d_name. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sat Oct  9 23:53:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Oct 2010 21:53:18 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>, ,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>,
	<1286563617.7401.68.camel@boromir.m3w.org>,
	<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
Message-ID: <COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>


> Idealized is you grow everything to LONGINT or INTEGER and sort by size,
> and copy back/forth with C. There will be no padding, guaranteed.

I sort of made up these rules btw, and then sort alphabetically.
And for good measure, during initialization, you can
pass a value or var/pointer of one of these structs to/from
C/Modula-3 and assert on the other side that it looks as expected.
 
 
For example:
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/TestC.c
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/Test.i3
  "CheckFloatsAndTypes"
 
I couldn't find where I call it.
I would be reasonble imho to put in m3core.
 Though the float stuff should be better thought out to have
  a complete but no extra test.
Maybe even passed from main to RTLinker.InitRuntime.
 
This is also done in:
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosixC.c
  function TypeCheck
 
 
To make sure the C and Modula-3 line up.
Note this isn't with "underlying C", but with our own C.
I moved things up a layer to avoid extra copying of struct tm,
and so I could #ifdef the 2 almost identical implementations into one.
 
 
 - Jay 		 	   		  

From dragisha at m3w.org  Sun Oct 10 01:50:43 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 10 Oct 2010 01:50:43 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,,<1286547420.7401.43.camel@boromir.m3w.org>
	,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	,<1286563617.7401.68.camel@boromir.m3w.org>
	,<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
	<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
Message-ID: <1286668243.7401.79.camel@boromir.m3w.org>

Eliminating key phrase being "out own C"...

I understand your approach here, and it's all OK - except it means ultra
extra work for large APIs like Gtk+ I am working with/on. To accomplish
things in our lifetimes, we have to automate things. It all boils down
to "parse .h somehow, and then manipulate AST's to produce pieces of C
and pieces of Modula-3". 

Looks a lot what SWIG does already, and I think it's nice place to
start. Get what they already learned from .h's and produce better
interfacing libraries. More concise and readable, at least.

On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> 
> Note this isn't with "underlying C", but with our own C. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sun Oct 10 08:52:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Oct 2010 06:52:49 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286668243.7401.79.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, , ,
	<1286547420.7401.43.camel@boromir.m3w.org>, ,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>, ,
	<1286563617.7401.68.camel@boromir.m3w.org>, ,
	<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>,
	<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>,
	<1286668243.7401.79.camel@boromir.m3w.org>
Message-ID: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>


Look at what others do?
 
Heck there is a C# binding. You can compile that
and reflect over its metadata.. should be able
to spit back out the original C headers?
 
 
Just Bing for "automate gtk binding"?
 
http://pwet.fr/man/linux/commandes/generate2
http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#autogeneration
 
etc.
 
Someone should make an interface language, that everyone
actually uses!
 
 - Jay



----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Sun, 10 Oct 2010 01:50:43 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> Eliminating key phrase being "out own C"...
>
> I understand your approach here, and it's all OK - except it means ultra
> extra work for large APIs like Gtk+ I am working with/on. To accomplish
> things in our lifetimes, we have to automate things. It all boils down
> to "parse .h somehow, and then manipulate AST's to produce pieces of C
> and pieces of Modula-3".
>
> Looks a lot what SWIG does already, and I think it's nice place to
> start. Get what they already learned from .h's and produce better
> interfacing libraries. More concise and readable, at least.
>
> On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> >
> > Note this isn't with "underlying C", but with our own C.
> --
> Dragi?a Duri? 
> 		 	   		  

From jay.krell at cornell.edu  Sun Oct 10 08:55:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Oct 2010 06:55:41 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>, , ,
	<1286547420.7401.43.camel@boromir.m3w.org>, ,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>, ,
	<1286563617.7401.68.camel@boromir.m3w.org>, ,
	<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>,
	<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>,
	<1286668243.7401.79.camel@boromir.m3w.org>,
	<COL101-W5840291BB9D967149038BBE6520@phx.gbl>
Message-ID: <COL101-W25D903D0121B17997EDFEEE6520@phx.gbl>


get gtk.defs from pygtk.
 
or
"It's worth noting that the "new way" to do things is with
gobject-introspection rather than a defs file (see pybank, gjs)"
 
etc.
 
 
 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] m3gap.... it's an alignment issue
> Date: Sun, 10 Oct 2010 06:52:49 +0000
>
>
> Look at what others do?
>
> Heck there is a C# binding. You can compile that
> and reflect over its metadata.. should be able
> to spit back out the original C headers?
>
>
> Just Bing for "automate gtk binding"?
>
> http://pwet.fr/man/linux/commandes/generate2
> http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#autogeneration
>
> etc.
>
> Someone should make an interface language, that everyone
> actually uses!
>
> - Jay
>
>
>
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: jay.krell at cornell.edu
> > Date: Sun, 10 Oct 2010 01:50:43 +0200
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] m3gap.... it's an alignment issue
> >
> > Eliminating key phrase being "out own C"...
> >
> > I understand your approach here, and it's all OK - except it means ultra
> > extra work for large APIs like Gtk+ I am working with/on. To accomplish
> > things in our lifetimes, we have to automate things. It all boils down
> > to "parse .h somehow, and then manipulate AST's to produce pieces of C
> > and pieces of Modula-3".
> >
> > Looks a lot what SWIG does already, and I think it's nice place to
> > start. Get what they already learned from .h's and produce better
> > interfacing libraries. More concise and readable, at least.
> >
> > On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> > >
> > > Note this isn't with "underlying C", but with our own C.
> > --
> > Dragi?a Duri?
> > 		 	   		  

From dragisha at m3w.org  Sun Oct 10 09:30:19 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 10 Oct 2010 09:30:19 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,,,<1286547420.7401.43.camel@boromir.m3w.org>
	,,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	,,<1286563617.7401.68.camel@boromir.m3w.org>
	,,<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
	,<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
	,<1286668243.7401.79.camel@boromir.m3w.org>
	<COL101-W5840291BB9D967149038BBE6520@phx.gbl>
Message-ID: <1286695819.7401.88.camel@boromir.m3w.org>

Of course... And I found lots of them uses regexp "parsers"... All
making same mistakes du to an EOL too many. No silver bullet there, but
even if there is one - Gtk+ is one example.

More important library (for me, of course) I am looking at is ffmpeg.
And few others. And their bindingness is not long enough present problem
to be as widely approached as Gtk+ is. 

On Sun, 2010-10-10 at 06:52 +0000, Jay K wrote:
> Look at what others do?
>  
> Heck there is a C# binding. You can compile that
> and reflect over its metadata.. should be able
> to spit back out the original C headers?
>  
> 
> Just Bing for "automate gtk binding"?
>  
> http://pwet.fr/man/linux/commandes/generate2
> http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#autogeneration
>  
> etc.
>  
> Someone should make an interface language, that everyone
> actually uses!
>  
>  - Jay
> 
> 
> 
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: jay.krell at cornell.edu
> > Date: Sun, 10 Oct 2010 01:50:43 +0200
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] m3gap.... it's an alignment issue
> >
> > Eliminating key phrase being "out own C"...
> >
> > I understand your approach here, and it's all OK - except it means ultra
> > extra work for large APIs like Gtk+ I am working with/on. To accomplish
> > things in our lifetimes, we have to automate things. It all boils down
> > to "parse .h somehow, and then manipulate AST's to produce pieces of C
> > and pieces of Modula-3".
> >
> > Looks a lot what SWIG does already, and I think it's nice place to
> > start. Get what they already learned from .h's and produce better
> > interfacing libraries. More concise and readable, at least.
> >
> > On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> > >
> > > Note this isn't with "underlying C", but with our own C.
> > --
> > Dragi?a Duri? 
> > 		 	   		  

-- 
Dragi?a Duri? <dragisha at m3w.org>



From dragisha at m3w.org  Sun Oct 10 09:31:38 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 10 Oct 2010 09:31:38 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,,,<1286547420.7401.43.camel@boromir.m3w.org>
	,,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	,,<1286563617.7401.68.camel@boromir.m3w.org>
	,,<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
	,<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
	,<1286668243.7401.79.camel@boromir.m3w.org>
	<COL101-W5840291BB9D967149038BBE6520@phx.gbl>
Message-ID: <1286695898.7401.89.camel@boromir.m3w.org>

Someone was, many times. But that didn't catch due to "It works, let's
go on" philosophy many schools are teaching.

On Sun, 2010-10-10 at 06:52 +0000, Jay K wrote:
> Someone should make an interface language, that everyone
> actually uses!
>   
-- 
Dragi?a Duri? <dragisha at m3w.org>



From dam at opencsw.org  Mon Oct 11 21:41:48 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 11 Oct 2010 21:41:48 +0200
Subject: [M3devel] Solaris/amd64
In-Reply-To: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
References: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
Message-ID: <6BC12B5F-5751-4F32-AA6E-8BC5FB8B0304@opencsw.org>

Hi Jay,

Am 07.10.2010 um 22:02 schrieb Jay K:
> There's a complete Solaris/amd64 in /home/jkrell/cm3.amd64 on the  
> opencsw machines having used 4.5.1 backend.
>   I can't test the X apps I think (not sure of the remoting).

Did I set up SSGD (X11-over-https) for you? This should make
redirection easy:
   https://sgd.opencsw.org


Best regards

   -- Dago




From jay.krell at cornell.edu  Tue Oct 12 00:35:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 11 Oct 2010 22:35:29 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W53AFBBF14A6AC6EA7745F2E6500@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>,
	<COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>,
	<COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>,
	<COL101-W53AFBBF14A6AC6EA7745F2E6500@phx.gbl>
Message-ID: <COL101-W63F21716075DE7A992C65CE6530@phx.gbl>


This is a really tough one to figure out.
I've tried making everything as returns_twice. No luck.
I'm not doing any optimization anyway.
  Though it looks like some optimizations might be done anyway,
  like converting jumps to jumps to single jump.
  I did some work to make 4.3 and 4.5 match, but not completely, and no luck so far.
 
 
I believe the problem isn't MxConfig per se. It is just that the 4.3
version doesn't use $l7 after calling M3File__IsReadable, so
is ok if $l7 isn't restored correctly.
 
 
I have to figure out, perhaps, where save/restore/return/ta3 store/load
the registers from and if that is getting corrupt.
I had trouble finding details on the SPARC stuff. (too much skimming by me) 
e.g. that the register windows are 16 registers in size,
that every non-leaf function must therefore have a frame of at least 64 bytes.
Er, the windows are actually 24 in size, but they overlap by 8, so 16 registers
might be saved/restored at each frame.
(Aside: I believe one of the flaws here is not register windows per se, but
fixed size register windows; I believe Itanium has effectively
variably sized register windows).
 
 
There's still stuff I don't understand -- how setjmp/longjmp/setcontext work.
 wrt SPARC specifically. I understand them otherwise.
 In a CS class in college I was actually tricked on a test by
 the "implement setjmp/longjmp for SPARC" question. I had implemented
 setjmp/longjmp for 65816 so I was overconfident, and just
 did simple register save/load. The trick at the time
 was explained to be "restore in a loop until the register window
 lines up". However that's not how SPARC longjmp looks wherever I checked
 in the past few days.
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Fri, 8 Oct 2010 11:44:57 +0000
>
>
> For the record:
> Still, no luck. Replacing MxConfig.ms from 4.3 seems to let it get further.
> Or maybe it was M*.
> Problem seems to be that when M3File__IsReadable returns, $l7 gets zeroed.
>
> But I'm going to try another hack.
>
> - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > Date: Thu, 7 Oct 2010 11:22:28 +0000
> >
> >
> > oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.
> >
> > - Jay
> >
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > > Date: Thu, 7 Oct 2010 09:45:49 +0000
> > >
> > >
> > > Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> > > I suspect we are underusing volatile.
> > > e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
> > > The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
> > >
> > > I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> > > all MODIFY_EXPR. There is probably redundancy here.
> > >
> > > Notice that even the original volatization was incomplete.
> > > It volatized current function's current temporaries/locals, but not others declared after
> > > any call to setjmp. I fixed that at some point.
> > >
> > > - Jay
> > >
> > > ----------------------------------------
> > > > From: jay.krell at cornell.edu
> > > > To: m3devel at elegosoft.com
> > > > Subject: random notes: gcc 4.5, sparc, etc.
> > > > Date: Wed, 6 Oct 2010 13:30:00 +0000
> > > >
> > > >
> > > > some random notes
> > > >
> > > > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > > > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > > > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> > > >
> > > > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > > > Same easy test, but it crashes upon first attempt to raise an exception.
> > > >
> > > > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > > > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> > > >
> > > > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > > > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> > > >
> > > > Meanwhile I think many other targets are working ok with 4.5.
> > > > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> > > >
> > > > - Jay
> > > >
> > >
> >
> 		 	   		  

From jay.krell at cornell.edu  Wed Oct 13 11:48:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Oct 2010 09:48:44 +0000
Subject: [M3devel] stack walker vs. gcc 4.5
Message-ID: <COL101-W4428AF300D518BD4AA4D5FE6550@phx.gbl>


I'm really really really really really really inclined to ditch using the one stack walker we use: SOLgnu/SOLsun/SPARC32_SOLARIS.
?I have been trying for quite a while to get it to work with the gcc 4.5 backend with no luck.


We could/should use the gcc exception handling support, thereby getting stack walking for most/all platforms.


Though odds are probably higher of generating C++ source and using exception handling there, and again, getting stack walking.
? (Or C on VMS/NT/OSF1 since they all have exception handling in C; NT/x86 doesn't really do stack walking, but
an optimized form of our non-stackwalking implementation)


?- Jay

 		 	   		  

From hosking at cs.purdue.edu  Wed Oct 13 16:56:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Oct 2010 10:56:34 -0400
Subject: [M3devel] stack walker vs. gcc 4.5
In-Reply-To: <COL101-W4428AF300D518BD4AA4D5FE6550@phx.gbl>
References: <COL101-W4428AF300D518BD4AA4D5FE6550@phx.gbl>
Message-ID: <F0708FBD-7C63-48CB-97BF-DE321B69EDBC@cs.purdue.edu>

Yes, agreed we should use gcc exception handling support.  It should not be that hard to use their stack walker.

On 13 Oct 2010, at 05:48, Jay K wrote:

> 
> I'm really really really really really really inclined to ditch using the one stack walker we use: SOLgnu/SOLsun/SPARC32_SOLARIS.
>  I have been trying for quite a while to get it to work with the gcc 4.5 backend with no luck.
> 
> 
> We could/should use the gcc exception handling support, thereby getting stack walking for most/all platforms.
> 
> 
> Though odds are probably higher of generating C++ source and using exception handling there, and again, getting stack walking.
>   (Or C on VMS/NT/OSF1 since they all have exception handling in C; NT/x86 doesn't really do stack walking, but
> an optimized form of our non-stackwalking implementation)
> 
> 
>  - Jay
> 
> 		 	   		  



From dabenavidesd at yahoo.es  Wed Oct 13 21:34:13 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 13 Oct 2010 20:34:13 +0100 (BST)
Subject: [M3devel] stack walker vs. gcc 4.5
In-Reply-To: <F0708FBD-7C63-48CB-97BF-DE321B69EDBC@cs.purdue.edu>
Message-ID: <79057.93087.qm@web29710.mail.ird.yahoo.com>

Hi all:
I was wondering what is about the Ultrix 4.3 bsd based stack walker and backend for the dec mips based ds3100. Should be a good thing to have some sort of restoration project team in that. Besides that, Utltrix source is publicly available now.
Just in case let me know who knows if anybody wants to look at it.
Thanks in advance 

--- El mi?, 13/10/10, Tony Hosking <hosking at cs.purdue.edu> escribi?:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] stack walker vs. gcc 4.5
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 13 de octubre, 2010 09:56
> Yes, agreed we should use gcc
> exception handling support.  It should not be that hard
> to use their stack walker.
> 
> On 13 Oct 2010, at 05:48, Jay K wrote:
> 
> > 
> > I'm really really really really really really inclined
> to ditch using the one stack walker we use:
> SOLgnu/SOLsun/SPARC32_SOLARIS.
> >  I have been trying for quite a while to get it
> to work with the gcc 4.5 backend with no luck.
> > 
> > 
> > We could/should use the gcc exception handling
> support, thereby getting stack walking for most/all
> platforms.
> > 
> > 
> > Though odds are probably higher of generating C++
> source and using exception handling there, and again,
> getting stack walking.
> >   (Or C on VMS/NT/OSF1 since they all
> have exception handling in C; NT/x86 doesn't really do stack
> walking, but
> > an optimized form of our non-stackwalking
> implementation)
> > 
> > 
> >  - Jay
> > 
> >    
>         
>           
>   
> 
> 


      


From jay.krell at cornell.edu  Thu Oct 14 05:56:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Oct 2010 03:56:18 +0000
Subject: [M3devel] my hudson nodes
Message-ID: <COL101-W3160FCBFC0EC1688099F33E6560@phx.gbl>


Nearly all of my Hudson nodes are down for now.
Maybe indefinitely.
Or will bring back only x86/AMD64 as VMs.
?(no Linux/sparc, Linux/powerpc, Solaris/sparc, but
we have Solaris/sparc otherwise, the rest are minor,
and others might rehost them at some point, or
I might)


?- Jay
 		 	   		  

From wagner at elegosoft.com  Thu Oct 14 09:56:17 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Oct 2010 09:56:17 +0200
Subject: [M3devel] my hudson nodes
Message-ID: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Nearly all of my Hudson nodes are down for now.
> Maybe indefinitely.
> Or will bring back only x86/AMD64 as VMs.
> ?(no Linux/sparc, Linux/powerpc, Solaris/sparc, but
> we have Solaris/sparc otherwise, the rest are minor,
> and others might rehost them at some point, or
> I might)

Hi Jay,

I feared as much when you offered all your hardware some time ago.
I didn't contact you then because I don't think it would make sense to
ship some of the machines to our offices in Europe (too expensive).

I think especially the xdarwin and xlinux nodes are still of interest
for M3 users. Perhaps somebody else can host those platforms?

Anyway, thank you very much for providing those build and test machines
for the recent years. I hope you just clear up the hardware zoo at your
home and don't plan to give up the work on M3 in general.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney_bates at lcwb.coop  Thu Oct 14 17:05:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 14 Oct 2010 10:05:46 -0500
Subject: [M3devel] my hudson nodes
In-Reply-To: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>
References: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>
Message-ID: <4CB71C4A.2050904@lcwb.coop>



Olaf Wagner wrote:
> Quoting Jay K <jay.krell at cornell.edu>:
> 
>> Nearly all of my Hudson nodes are down for now.
>> Maybe indefinitely.
>> Or will bring back only x86/AMD64 as VMs.
>>  (no Linux/sparc, Linux/powerpc, Solaris/sparc, but
>> we have Solaris/sparc otherwise, the rest are minor,
>> and others might rehost them at some point, or
>> I might)
> 
> Hi Jay,
> 
> I feared as much when you offered all your hardware some time ago.
> I didn't contact you then because I don't think it would make sense to
> ship some of the machines to our offices in Europe (too expensive).
> 
> I think especially the xdarwin and xlinux nodes are still of interest
> for M3 users. Perhaps somebody else can host those platforms?

If/when I manage to get a better internet connection, I could host a few.
Right now, I'm stuck with a satellite connection which, aside from being
somewhat slow on bit rate and absolutely glacial on latency, has draconian
bit quotas, both up and down.  And they slow it down a whole lot more if I
exceed them.  It's the only drawback to living out in tallgrass prairie,
which is in all other respects, wonderful.  I continue to work on
alternatives.

> 
> Anyway, thank you very much for providing those build and test machines
> for the recent years. I hope you just clear up the hardware zoo at your
> home and don't plan to give up the work on M3 in general.
> 
> Olaf


From jay.krell at cornell.edu  Thu Oct 14 23:24:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Oct 2010 21:24:14 +0000
Subject: [M3devel] my hudson nodes
In-Reply-To: <4CB71C4A.2050904@lcwb.coop>
References: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>,
	<4CB71C4A.2050904@lcwb.coop>
Message-ID: <COL101-W292F0316E8E53E567884DFE6560@phx.gbl>


xdarwin is a laptop I use regularly. It will stay. It isn't always on.
xlinux is also a laptop and is among first in line to come back or be replaced with a VM on xdarwin.
The vast majority of my hardware has never been Hudson nodes.
But yes it is related.

?- Jay


----------------------------------------
> Date: Thu, 14 Oct 2010 10:05:46 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] my hudson nodes
>
>
>
> Olaf Wagner wrote:
> > Quoting Jay K :
> >
> >> Nearly all of my Hudson nodes are down for now.
> >> Maybe indefinitely.
> >> Or will bring back only x86/AMD64 as VMs.
> >> (no Linux/sparc, Linux/powerpc, Solaris/sparc, but
> >> we have Solaris/sparc otherwise, the rest are minor,
> >> and others might rehost them at some point, or
> >> I might)
> >
> > Hi Jay,
> >
> > I feared as much when you offered all your hardware some time ago.
> > I didn't contact you then because I don't think it would make sense to
> > ship some of the machines to our offices in Europe (too expensive).
> >
> > I think especially the xdarwin and xlinux nodes are still of interest
> > for M3 users. Perhaps somebody else can host those platforms?
>
> If/when I manage to get a better internet connection, I could host a few.
> Right now, I'm stuck with a satellite connection which, aside from being
> somewhat slow on bit rate and absolutely glacial on latency, has draconian
> bit quotas, both up and down. And they slow it down a whole lot more if I
> exceed them. It's the only drawback to living out in tallgrass prairie,
> which is in all other respects, wonderful. I continue to work on
> alternatives.
>
> >
> > Anyway, thank you very much for providing those build and test machines
> > for the recent years. I hope you just clear up the hardware zoo at your
> > home and don't plan to give up the work on M3 in general.
> >
> > Olaf
 		 	   		  

From michael.anderson at elego.de  Fri Oct 15 12:05:18 2010
From: michael.anderson at elego.de (Michael Anderson)
Date: Fri, 15 Oct 2010 12:05:18 +0200
Subject: [M3devel] [elego Server Maintenance] Friday 15.10.2010 20:00
Message-ID: <20101015120518.8q3kbjqmo88kkwoo@mail.elegosoft.com>

Hello,

On Friday, October 15 at 8 PM CEST, we will perform scheduled
maintenance on our servers.
Brief interruptions of service may occur.
Expected duration: 120 Min.

We apologize for any inconvenience.

- the elego Admins


-- 
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194




From jay.krell at cornell.edu  Sat Oct 16 14:18:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Oct 2010 12:18:53 +0000
Subject: [M3devel] bootstrapping wrinkle,
 incrementality bug when toggling build_standalone
Message-ID: <COL101-W11D13E1A83111DB860A770E6580@phx.gbl>


I found a new bootstrapping wrinkle tonight.
Based on that we typically have pairs of libraries:
NT: foo.lib, foo.lib.sa
Posix: libfoo.a, libfoo.a.sa?
 
 
If there is incompatibility introduced in m3core,
such as I introduced just now for set_member/set_singleton,
it *seems* you can get into a situation where only
one of the two libraries is updated.
 
 
Perhaps because I was hacking shared = false, perhaps
to workaround other problems.
 
 
Anyway, the general technique might be useful.
 ==> move foo.lib.sa to foo.lib
 
 
More generally there IS an obvious problem in the system.
IF I have a library that was previously not standalone,
therefore having both foo.lib and foo.lib.sa,
 
 
and then I change it to always be standalone,
therefore only having foo.lib,
 
 
and then I link a standalone application to it,
the out of date foo.lib.sa will be found and used.
 
 
Solutions include:
 - when shipping, delete related neighboring files.
   i.e. when shipping a non-standalone library, delete the shipped foo.lib.sa.
 - or, always make foo.lib and foo.lib.sa, just that
   they might be identical.
 - or, lame...probe contents not name? if foo.lib appears to be
   standalone, don't probe for foo.lib.sa? Not difficult on NT...
 
 
(This goes to show something I can never very well explain why:
file existance checks, probes, generally indicate problems.)
 
 
 - Jay
  		 	   		  

From jay.krell at cornell.edu  Sun Oct 17 02:27:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Oct 2010 00:27:11 +0000
Subject: [M3devel] firming up atomics?
Message-ID: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>


Tony,

Can we firm up the atomic semantics/implementatino?

Now might be a good time for me to make the NT/x86 backend
definitely work, test it, and make it more efficient.
? (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
?
?
Like, old value vs. new value returned?


Off the cuff, I'd say, better to always return old value.
The new value can always be computed from it.

However we are the mercy of the processors.


And it only matters for or/and.
xor/add/sub/inc/dec can all compute either from either.


Also, please, I don't find the specifications clear.
At least the last time I studied them.


To me they should say, things like,
?"returns the old value" 
?or "returns the new value" 

?
or returns true if compare matched
or returns false if the compare matched
etc.


The mentions of "spurious failure" or whatnot didn't make sense either.
They should say, something like:
returns true if the compare matched
?but sometimes even if the compare should have matched,
?it won't, and false will be returned -- specify everything that happens when there is "failure".

?
Furthermore, if you look at what Microsoft compilers provide,
they provide a bunch of very simple very clear well documented functions,
that the compiler implements and inlines.
?(at least if you ignore the qcuire/release stuff that confuses me...


You could specify in terms of them.
?Really. A good idea.


ie: is our compare_exchange equivalent to InterlockedCompareExchange?
? Or maybe parameter order different?

? 
Of course, I understand, the types supported by the Microsoft
intrinsics have varied through time and slowly grown.
8bit and 16bit might still be lacking but 32bit and 64bit are very
complete. 64bit atomic operations on 32bit x86 processors 
since Pentium or so can be synthesized with a loop over
InterlockedCompareExchange64.


Or in terms of the gcc intrinsics, probably similarly ok.


We should probably also nail down the implementation where
they aren't available.


And maybe put in safer defaults?
? And quickly improve where we can, e.g. on all x86/AMD64 platforms.
? 

?Thanks,
?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Sun Oct 17 14:48:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Oct 2010 08:48:09 -0400
Subject: [M3devel] firming up atomics?
In-Reply-To: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>
References: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>
Message-ID: <FF060A4B-7136-4FA7-89BB-712B96FC710B@cs.purdue.edu>

I still have some fixes to check in before turning it on again.
They are intended to match the approved C++0x standard.

On 16 Oct 2010, at 20:27, Jay K wrote:

> 
> Tony,
> 
> Can we firm up the atomic semantics/implementatino?
> 
> Now might be a good time for me to make the NT/x86 backend
> definitely work, test it, and make it more efficient.
>   (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
>  
>  
> Like, old value vs. new value returned?
> 
> 
> Off the cuff, I'd say, better to always return old value.
> The new value can always be computed from it.
> 
> However we are the mercy of the processors.
> 
> 
> And it only matters for or/and.
> xor/add/sub/inc/dec can all compute either from either.
> 
> 
> Also, please, I don't find the specifications clear.
> At least the last time I studied them.
> 
> 
> To me they should say, things like,
>  "returns the old value" 
>  or "returns the new value" 
> 
>  
> or returns true if compare matched
> or returns false if the compare matched
> etc.
> 
> 
> The mentions of "spurious failure" or whatnot didn't make sense either.
> They should say, something like:
> returns true if the compare matched
>  but sometimes even if the compare should have matched,
>  it won't, and false will be returned -- specify everything that happens when there is "failure".
> 
>  
> Furthermore, if you look at what Microsoft compilers provide,
> they provide a bunch of very simple very clear well documented functions,
> that the compiler implements and inlines.
>  (at least if you ignore the qcuire/release stuff that confuses me...
> 
> 
> You could specify in terms of them.
>  Really. A good idea.
> 
> 
> ie: is our compare_exchange equivalent to InterlockedCompareExchange?
>   Or maybe parameter order different?
> 
>   
> Of course, I understand, the types supported by the Microsoft
> intrinsics have varied through time and slowly grown.
> 8bit and 16bit might still be lacking but 32bit and 64bit are very
> complete. 64bit atomic operations on 32bit x86 processors 
> since Pentium or so can be synthesized with a loop over
> InterlockedCompareExchange64.
> 
> 
> Or in terms of the gcc intrinsics, probably similarly ok.
> 
> 
> We should probably also nail down the implementation where
> they aren't available.
> 
> 
> And maybe put in safer defaults?
>   And quickly improve where we can, e.g. on all x86/AMD64 platforms.
>   
> 
>  Thanks,
>  - Jay
> 		 	   		  



From ttmrichter at gmail.com  Mon Oct 18 19:08:07 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Tue, 19 Oct 2010 01:08:07 +0800
Subject: [M3devel] CM3, Windows and GCC
Message-ID: <AANLkTikK=HwxCsGtpHSe__KzNWOzjg54a0v8pwocU=WM@mail.gmail.com>

Is there any way through, say, MinGW (or, if absolutely necessary, Cygwin)
to get the back-end for CM3 to target GCC on Windows instead of Microsoft's
tool chain?

-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101019/c425ee8e/attachment-0001.html>

From jay.krell at cornell.edu  Tue Oct 19 08:48:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 19 Oct 2010 06:48:32 +0000
Subject: [M3devel] firming up atomics?
In-Reply-To: <FF060A4B-7136-4FA7-89BB-712B96FC710B@cs.purdue.edu>
References: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>,
	<FF060A4B-7136-4FA7-89BB-712B96FC710B@cs.purdue.edu>
Message-ID: <COL101-W40DE4DFA20016824C36938E65B0@phx.gbl>


Tony, hm, the full generality, in the backend, I think it should be a parameter whether or not the old value or new value or both or neither are returned.
 
See how the Microsoft intrinsics return the old value, but the x86 instructions return the new value, necessitating compare/exchange loops, unless the value is ignored, in which case much more efficient:
 
"v" for void:
 
void __fastcall vor(long a, long b) { _InterlockedOr(a, b); }
long __fastcall or(long a, long b) { return _InterlockedOr(a, b); }
 
void __fastcall vxor(long a, long b) { _InterlockedXor(a, b); }
long __fastcall xor(long a, long b) { return _InterlockedXor(a, b); }
 
void __fastcall vand(long a, long b) { _InterlockedAnd(a, b); }
long __fastcall and(long a, long b) { return _InterlockedAnd(a, b); }

 
C:\>cl -c 1.c -FAsc -Ox && more 1.cod

; 3    : void __fastcall vor(long a, long b) { _InterlockedOr(a, b); }
  00000 f0 09 11         lock     or     DWORD PTR [ecx], edx
  00003 c3               ret     0

; 4    : long __fastcall or(long a, long b) { return _InterlockedOr(a, b); }
  00010 56               push    esi
  00011 8b 01            mov     eax, DWORD PTR [ecx]
$LN3@:
  00013 8b f0            mov     esi, eax
  00015 0b f2            or      esi, edx
  00017 f0 0f b1 31      lock     cmpxchg DWORD PTR [ecx], esi
  0001b 75 f6            jne     SHORT $LN3@
  0001d 5e               pop     esi
  0001e c3               ret     0

 
; 6    : void __fastcall vxor(long a, long b) { _InterlockedXor(a, b); }
  00020 f0 31 11         lock     xor    DWORD PTR [ecx], edx
  00023 c3               ret     0

 
; 7    : long __fastcall xor(long a, long b) { return _InterlockedXor(a, b); }
  00030 56               push    esi
  00031 8b 01            mov     eax, DWORD PTR [ecx]
$LN3@:
  00033 8b f0            mov     esi, eax
  00035 33 f2            xor     esi, edx
  00037 f0 0f b1 31      lock     cmpxchg DWORD PTR [ecx], esi
  0003b 75 f6            jne     SHORT $LN3@
  0003d 5e               pop     esi
  0003e c3               ret     0

 
; 9    : void __fastcall vand(long a, long b) { _InterlockedAnd(a, b); }
  00040 f0 21 11         lock     and    DWORD PTR [ecx], edx
  00043 c3               ret     0

 
; 10   : long __fastcall and(long a, long b) { return _InterlockedAnd(a, b); }
  00050 56               push    esi
  00051 8b 01            mov     eax, DWORD PTR [ecx]
$LN3@:
  00053 8b f0            mov     esi, eax
  00055 23 f2            and     esi, edx
  00057 f0 0f b1 31      lock     cmpxchg DWORD PTR [ecx], esi
  0005b 75 f6            jne     SHORT $LN3@
  0005d 5e               pop     esi
  0005e c3               ret     0
@and at 8  ENDP
_TEXT   ENDS
END
 
 
 - Jay


 
> Subject: Re: [M3devel] firming up atomics?
> From: hosking at cs.purdue.edu
> Date: Sun, 17 Oct 2010 08:48:09 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I still have some fixes to check in before turning it on again.
> They are intended to match the approved C++0x standard.
> 
> On 16 Oct 2010, at 20:27, Jay K wrote:
> 
> > 
> > Tony,
> > 
> > Can we firm up the atomic semantics/implementatino?
> > 
> > Now might be a good time for me to make the NT/x86 backend
> > definitely work, test it, and make it more efficient.
> > (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
> > 
> > 
> > Like, old value vs. new value returned?
> > 
> > 
> > Off the cuff, I'd say, better to always return old value.
> > The new value can always be computed from it.
> > 
> > However we are the mercy of the processors.
> > 
> > 
> > And it only matters for or/and.
> > xor/add/sub/inc/dec can all compute either from either.
> > 
> > 
> > Also, please, I don't find the specifications clear.
> > At least the last time I studied them.
> > 
> > 
> > To me they should say, things like,
> > "returns the old value" 
> > or "returns the new value" 
> > 
> > 
> > or returns true if compare matched
> > or returns false if the compare matched
> > etc.
> > 
> > 
> > The mentions of "spurious failure" or whatnot didn't make sense either.
> > They should say, something like:
> > returns true if the compare matched
> > but sometimes even if the compare should have matched,
> > it won't, and false will be returned -- specify everything that happens when there is "failure".
> > 
> > 
> > Furthermore, if you look at what Microsoft compilers provide,
> > they provide a bunch of very simple very clear well documented functions,
> > that the compiler implements and inlines.
> > (at least if you ignore the qcuire/release stuff that confuses me...
> > 
> > 
> > You could specify in terms of them.
> > Really. A good idea.
> > 
> > 
> > ie: is our compare_exchange equivalent to InterlockedCompareExchange?
> > Or maybe parameter order different?
> > 
> > 
> > Of course, I understand, the types supported by the Microsoft
> > intrinsics have varied through time and slowly grown.
> > 8bit and 16bit might still be lacking but 32bit and 64bit are very
> > complete. 64bit atomic operations on 32bit x86 processors 
> > since Pentium or so can be synthesized with a loop over
> > InterlockedCompareExchange64.
> > 
> > 
> > Or in terms of the gcc intrinsics, probably similarly ok.
> > 
> > 
> > We should probably also nail down the implementation where
> > they aren't available.
> > 
> > 
> > And maybe put in safer defaults?
> > And quickly improve where we can, e.g. on all x86/AMD64 platforms.
> > 
> > 
> > Thanks,
> > - Jay
> > 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101019/d4c27182/attachment-0001.html>

From jay.krell at cornell.edu  Tue Oct 19 12:39:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 19 Oct 2010 10:39:35 +0000
Subject: [M3devel] CM3, Windows and GCC
In-Reply-To: <AANLkTikK=HwxCsGtpHSe__KzNWOzjg54a0v8pwocU=WM@mail.gmail.com>
References: <AANLkTikK=HwxCsGtpHSe__KzNWOzjg54a0v8pwocU=WM@mail.gmail.com>
Message-ID: <COL101-W761547F7BEDE16B44EB9DE65B0@phx.gbl>


Yes, both such targets exist, I386_CYGWIN and I386_MINGW.
Nobody uses them. But they are there and have worked in the past.
Maybe time to make sure they work and keep them working (Hudson).
 
 
However you have somewhat confused apples/oranges.
Somewhat. We have our own builtin code generator. We only use
Microsoft tools for 1) a little bit of C 2) linker 3) C runtime.
You ought to be able to combine either backend with either runtime and either C compiler and either linker. Though I noticed the C runtimes are somewhat tied to the linkers.
 
Note that our builtin code generator generates pretty good code and does it fast.
 
MinGW is probably the way to go for "AMD64_NT" though.
  Or the proverbial C backend.
 
 
 - Jay


________________________________
> Date: Tue, 19 Oct 2010 01:08:07 +0800
> From: ttmrichter at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] CM3, Windows and GCC
>
> Is there any way through, say, MinGW (or, if absolutely necessary,
> Cygwin) to get the back-end for CM3 to target GCC on Windows instead of
> Microsoft's tool chain?
>
> -- 		 	   		  

From jay.krell at cornell.edu  Sat Oct 23 12:06:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Oct 2010 10:06:39 +0000
Subject: [M3devel] typenames vs. lexical scope vs. backend?
Message-ID: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>


Um.. the same name can be different types, in different scopes.


<*NOWARN*>PROCEDURE F1() =
TYPE T1 = INTEGER;
BEGIN
END F1;

<*NOWARN*>PROCEDURE F2() =
TYPE T1 = LONGINT;
BEGIN
END F2;

=>

(16) declare_procedure name:Main__F1 n_params:0 return_type:void lev:0 exported:false
(17) declare_typename my_id:0x195C2A74 name:T1

(18) declare_procedure name:Main__F2 n_params:0 return_type:void lev:0 exported:false
(19) declare_typename my_id:0x5562176 name:T1
(20) comment comment:F1
(21) set_source_line 6

(22) begin_procedure procedure:Main__F1
(23)???? set_source_line 7
(24)???? set_source_line 9
(25)???? exit_proc type:void
(26) end_procedure procedure:Main__F1

(27) comment comment:F2
(28) set_source_line 0xB(11)
(29) begin_procedure procedure:Main__F2
(30)???? set_source_line 0xC(12)
(31)???? set_source_line 0xE(14)
(32)???? exit_proc type:void
(33) end_procedure procedure:Main__F2


Is the backend to record the types within some scope, and then observe
the scopes coming back?


Or, then again, are typenames worth much to the backend?
Well, maybe.
They aren't needed for display the values of variables,
but they might be nice in expressions that include casts?

I'm thinking maybe the right thing is to ignore them in the backend.
??

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Sat Oct 23 20:04:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 23 Oct 2010 14:04:12 -0400
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
Message-ID: <E2C44EC5-93F6-4063-9224-316DDA91100E@cs.purdue.edu>

You could mangle the name to prefix the scope.

On 23 Oct 2010, at 06:06, Jay K wrote:

> 
> Um.. the same name can be different types, in different scopes.
> 
> 
> <*NOWARN*>PROCEDURE F1() =
> TYPE T1 = INTEGER;
> BEGIN
> END F1;
> 
> <*NOWARN*>PROCEDURE F2() =
> TYPE T1 = LONGINT;
> BEGIN
> END F2;
> 
> =>
> 
> (16) declare_procedure name:Main__F1 n_params:0 return_type:void lev:0 exported:false
> (17) declare_typename my_id:0x195C2A74 name:T1
> 
> (18) declare_procedure name:Main__F2 n_params:0 return_type:void lev:0 exported:false
> (19) declare_typename my_id:0x5562176 name:T1
> (20) comment comment:F1
> (21) set_source_line 6
> 
> (22) begin_procedure procedure:Main__F1
> (23)     set_source_line 7
> (24)     set_source_line 9
> (25)     exit_proc type:void
> (26) end_procedure procedure:Main__F1
> 
> (27) comment comment:F2
> (28) set_source_line 0xB(11)
> (29) begin_procedure procedure:Main__F2
> (30)     set_source_line 0xC(12)
> (31)     set_source_line 0xE(14)
> (32)     exit_proc type:void
> (33) end_procedure procedure:Main__F2
> 
> 
> Is the backend to record the types within some scope, and then observe
> the scopes coming back?
> 
> 
> Or, then again, are typenames worth much to the backend?
> Well, maybe.
> They aren't needed for display the values of variables,
> but they might be nice in expressions that include casts?
> 
> I'm thinking maybe the right thing is to ignore them in the backend.
> ??
> 
>  - Jay
> 		 	   		  



From dragisha at m3w.org  Sat Oct 23 21:44:16 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 23 Oct 2010 21:44:16 +0200
Subject: [M3devel] Runtime only package for Windows? With preselected
	modules?
Message-ID: <1287863056.19814.1585.camel@boromir.m3w.org>

I have a rpm spec file I am using and it by default makes cm3 package
and cm3-devel. Also, it does not contain all modula-3 packages, as most
of them are not used in typical cases.

Right now I am about to make install package for an application I am
delivering and runtime libs only package for Windows is what is on my
mind right now. Doable? Or I can skip it without problem with
build_standalone() ? How do I confirm it's statically linked? Under
linux I'll use ldd, but depends.exe (thanks Jay) does not show it to
me...Or it does?
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sun Oct 24 02:30:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Oct 2010 00:30:52 +0000
Subject: [M3devel] Runtime only package for Windows? With preselected
 modules?
In-Reply-To: <1287863056.19814.1585.camel@boromir.m3w.org>
References: <1287863056.19814.1585.camel@boromir.m3w.org>
Message-ID: <COL101-W408980139AB55C72705EC0E6400@phx.gbl>


With build_standalone you don't need to worry.
  As long as all your Modula-3 code is in one .dll per process.
  Er, I mean, as long as your Modula-3 is the .exe and no .dlls.


There is some need for shared state sometimes.
But if all the Modula-3 code is linked together, in the .exe, ok.


You know, imagine you have multiple Modula-3 .dlls loaded, standalone.
Which garbage collector? Maybe all of them, against their own allocations.
Maybe it is jus slow.


But what if you pass off Modula-3 traced references across .dll boundaries,
without sharing a garbage collector (m3core.dll). Then you'd have trouble.


This has nothing to do with Windows.
It is the general hazard of dynamic linking.


Sometimes dynamic linking is an opportunistic optimization.
  e.g. it doesn't matter if you share strlen or not. It is stateless. You can have
  any number of copies. More efficient to reduce, but not a big deal these days,
  with tons of disk space and address space and physical memory.


But sometimes a .dll is managing a shared resource.
e.g. some global variables.
Then having multiple copies of data/code can be confusing or very wrong.
e.g. consider something like setlocale().
Which code does it affect? Only code using the same C runtime.


Imagine I call fopen or malloc and give the result to another .dll that
calls fread or free. They have to share the same C runtime.
Or in a less likely case, the multiple C runtimes have to cooperate.


Same problem with CreateFile/ReadFile/CloseHandle, except
the system doesn't allow duplicate kernel32.dll or the underlying ntoskrnl.exe.


Think of "services".
For example there is "BITS" the background intelligent transfer service..
used by Windows Update. If you have more than one on a machine,
then the "background" and "intelligent" suffer.
But it'd still mostly work?


 - Jay

> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Sat, 23 Oct 2010 21:44:16 +0200
> Subject: [M3devel] Runtime only package for Windows? With preselected	modules?
> 
> I have a rpm spec file I am using and it by default makes cm3 package
> and cm3-devel. Also, it does not contain all modula-3 packages, as most
> of them are not used in typical cases.
> 
> Right now I am about to make install package for an application I am
> delivering and runtime libs only package for Windows is what is on my
> mind right now. Doable? Or I can skip it without problem with
> build_standalone() ? How do I confirm it's statically linked? Under
> linux I'll use ldd, but depends.exe (thanks Jay) does not show it to
> me...Or it does?
> -- 
> Dragi?a Duri? <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101024/56e18a25/attachment-0001.html>

From rodney_bates at lcwb.coop  Sun Oct 24 02:50:04 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 23 Oct 2010 19:50:04 -0500
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
Message-ID: <4CC382BC.2080509@lcwb.coop>

No different from names of variables, formals, constants, or procedures.
I can't think why the backend would need them for code generation/optimization.

They do belong in debug info, however.  This happens now for type names in
stabs+ debug output, although the encoding is a mess, and quite different
from variables, etc.  m3gdb recognizes them in debug commands and applies
the usual scope rules in doing so.  They can be used, e.g. in LOOPHOLE.
In a few cases, m3gdb will give you a bit of structural description of
a type, but often just fully qualifies the type name and repeats that.
When there are multiple names for the same (structurally) type, it is you may
get a synonym type name.

I suspect there is some internal backend tracing that would also benefit from
type names, as with variables, etc.


Jay K wrote:
> Um.. the same name can be different types, in different scopes.
> 
> 
> <*NOWARN*>PROCEDURE F1() =
> TYPE T1 = INTEGER;
> BEGIN
> END F1;
> 
> <*NOWARN*>PROCEDURE F2() =
> TYPE T1 = LONGINT;
> BEGIN
> END F2;
> 
> =>
> 
> (16) declare_procedure name:Main__F1 n_params:0 return_type:void lev:0 exported:false
> (17) declare_typename my_id:0x195C2A74 name:T1
> 
> (18) declare_procedure name:Main__F2 n_params:0 return_type:void lev:0 exported:false
> (19) declare_typename my_id:0x5562176 name:T1
> (20) comment comment:F1
> (21) set_source_line 6
> 
> (22) begin_procedure procedure:Main__F1
> (23)     set_source_line 7
> (24)     set_source_line 9
> (25)     exit_proc type:void
> (26) end_procedure procedure:Main__F1
> 
> (27) comment comment:F2
> (28) set_source_line 0xB(11)
> (29) begin_procedure procedure:Main__F2
> (30)     set_source_line 0xC(12)
> (31)     set_source_line 0xE(14)
> (32)     exit_proc type:void
> (33) end_procedure procedure:Main__F2
> 
> 
> Is the backend to record the types within some scope, and then observe
> the scopes coming back?
> 
> 
> Or, then again, are typenames worth much to the backend?
> Well, maybe.
> They aren't needed for display the values of variables,
> but they might be nice in expressions that include casts?
> 
> I'm thinking maybe the right thing is to ignore them in the backend.
> ??
> 
>  - Jay
>  		 	   		  


From dragisha at m3w.org  Sun Oct 24 07:59:51 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 24 Oct 2010 07:59:51 +0200
Subject: [M3devel] Runtime only package for Windows? With preselected
 modules?
In-Reply-To: <COL101-W408980139AB55C72705EC0E6400@phx.gbl>
References: <1287863056.19814.1585.camel@boromir.m3w.org>
	<COL101-W408980139AB55C72705EC0E6400@phx.gbl>
Message-ID: <1287899991.19814.1680.camel@boromir.m3w.org>

Thank you for elaborate answer.

I did build_standalone() and so far so good... It only pulls system libs
as .dlls (and it is clearly visible by depends.exe) and C libs I
linked. 

Under Linux I changed link command so it linked part of these libs
statically too... I think we need more control there (previously
discussed import_static()). C people have that curse|control point where
they have to specify their link commands, but we probably need to
recognize patterns so we can abstract in m3makefiles and pass them on to
lower levels.

I do not agree on "big physical memory and everything..". No matter how
spacious modern computers are, bad design can chew all that in no time.
Same is true for processor speeds and we all recognize that, but we
easily forget about space being other leg of software/algorightm
efficiency.

On Sun, 2010-10-24 at 00:30 +0000, Jay K wrote:
> With build_standalone you don't need to worry.
>   As long as all your Modula-3 code is in one .dll per process.
>   Er, I mean, as long as your Modula-3 is the .exe and no .dlls.
> 
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Mon Oct 25 02:15:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 25 Oct 2010 00:15:46 +0000
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <4CC382BC.2080509@lcwb.coop>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>,
	<4CC382BC.2080509@lcwb.coop>
Message-ID: <COL101-W48B2A9FB06B01EA23B2E4DE6410@phx.gbl>


> No different from names of variables, formals, constants, or procedures.
> I can't think why the backend would need them for code generation/optimization.

 
For debugging.
 

> They do belong in debug info, however.
 
 
Exactly. Maybe.
Except, I'm thinking..maybe only for entering expressions with casts?
Maybe not for viewing any values?
 
I think the way the compiler is currently structured, it is a lot of work to get this right,
and not with much gain.
The gain would be that typenames in expressions with casts would be 1) evaluated
relative to context 2) easier...typenames should probably be lengthened
in order to have a context-independent name. The lexical scopes
that introduce type names, in order of decreasing frequency would be roughly:
  module
  toplevel function in a module
  block or nested function 
 
We could qualify typenames with Module or Module.Function or Module.Function.NestedFunction.
There's no obvious good name for blocks (WITH, FOR, etc.), but maybe numbers 0, 1, 2, etc.
 
 
I think the frontend and frontend/backend interface need work.
In this case there's not much to gain.
I'll cover something else in a separate mail.
 
 
 - Jay
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101025/675b348f/attachment-0001.html>

From jay.krell at cornell.edu  Mon Oct 25 02:21:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 25 Oct 2010 00:21:43 +0000
Subject: [M3devel] backend and field/array references
Message-ID: <COL101-W293BBD4A33BC418CA80B56E6410@phx.gbl>


The frontend/backend interface should have notions of record field accesses and array indexing.
I'm not sure exactly what they should look like but it shouldn't be difficult to figure out,
at least some simple approaches that scale well enough, even if not ideally.
 
 
For example, every field in a record should either have an id 0, 1, 2, etc. allocated within the record.
OR every field in a record should have an id a la hashes/fingerprints, that could be
sorted/searched globally, even if that isn't as efficient as it could be.
 
 
What I'll probably get working before any of this is in m3_load/store, do a linear search within
the fields of the variable for a field whose offset/size matches.
But linearch search is almost never a good solution.
It could be implemented as binary search with the current interface.
 
 
Due to the danger of layout mismatch, I'm plenty willing for field/array accesses to include
with them the offset the frontend believes them to be at, and it'd be a checked internal error
in the backend if the frontend and backend offset/size disagree.
This would also aid backends that don't have such a high level internal representation (i.e.: NT386).
 
 
I have something prototyped here and it somewhat works.
I have a check that all accesses can be have a field deduced for them.
The first place that fails is for open arrays, for obvious reasons, which I'll fix.
I'll see how it goes from there.
 
 
Ultimately I'm still keen on a C-generating frontend, which does not moot this.
  It would allow for more sensible C to be generated.
 
 
 
 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101025/cf3720ff/attachment-0001.html>

From rodney_bates at lcwb.coop  Mon Oct 25 19:17:48 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 25 Oct 2010 12:17:48 -0500
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <COL101-W48B2A9FB06B01EA23B2E4DE6410@phx.gbl>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>,
	<4CC382BC.2080509@lcwb.coop>
	<COL101-W48B2A9FB06B01EA23B2E4DE6410@phx.gbl>
Message-ID: <4CC5BBBC.5070206@lcwb.coop>



Jay K wrote:
>  > No different from names of variables, formals, constants, or procedures.
>  > I can't think why the backend would need them for code 
> generation/optimization.
> 
>  
> For debugging.
>  
> 
>  > They do belong in debug info, however.
>  
>  
> Exactly. Maybe.
> Except, I'm thinking..maybe only for entering expressions with casts?
> Maybe not for viewing any values?
>  
> I think the way the compiler is currently structured, it is a lot of 
> work to get this right,
> and not with much gain.
> The gain would be that typenames in expressions with casts would be 1) 
> evaluated
> relative to context 2) easier...typenames should probably be lengthened
> in order to have a context-independent name. The lexical scopes
> that introduce type names, in order of decreasing frequency would be 
> roughly:
>   module
>   toplevel function in a module
>   block or nested function
>  
> We could qualify typenames with Module or Module.Function or 
> Module.Function.NestedFunction.
> There's no obvious good name for blocks (WITH, FOR, etc.), but maybe 
> numbers 0, 1, 2, etc.

Whether it's either obvious or good remains subject to debate, but there is already
a system for this, used by m3gdb.  See doc/help/m3gdb/m3gdb-onepage.html, section
"linespecs that are qualified references".  As for the subterfuge behind the scenes,
wherein the compiler and m3gdb communicate info through stabs+, it's a mess.

>  
>  
> I think the frontend and frontend/backend interface need work.
> In this case there's not much to gain.
> I'll cover something else in a separate mail.
>  
>  
>  - Jay
>  


From jay.krell at cornell.edu  Wed Oct 27 09:24:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 07:24:09 +0000
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
Message-ID: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>


My Linux/x86 and OpenBSD/x86 nodes are back from a few days ago.
?? err..need to check if they are working..

I'm experimenting with using Amazon Web Services though.
Reserved micro instances are about $7/month if I computed correctly and the first is free for the first year.
Unclear how easy OpenBSD/NetBSD etc. are to run there though.
? Or maybe just slow (i.e. not paravirtualized)
I'm seeing stuff in German lately in Hudson, but I understand very little German.
It looks like cvs/gcc is moving?
?Or all of cm3/cvs?


e.g.: http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console

http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console


(implied: others here should probably setup some instances, at least if non-Linux proves easy enough;
I'll try OpenBSD probably first)

?- Jay
 		 	   		  

From wagner at elegosoft.com  Wed Oct 27 10:04:09 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 27 Oct 2010 10:04:09 +0200
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
In-Reply-To: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>
References: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>
Message-ID: <20101027100409.3807ovva8gs80os4@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> My Linux/x86 and OpenBSD/x86 nodes are back from a few days ago.
> ?? err..need to check if they are working..
>
> I'm experimenting with using Amazon Web Services though.
> Reserved micro instances are about $7/month if I computed correctly   
> and the first is free for the first year.
> Unclear how easy OpenBSD/NetBSD etc. are to run there though.
> ? Or maybe just slow (i.e. not paravirtualized)

I haven't tried that yet; but if you want to set up a test node there,
that would be welcome.

> I'm seeing stuff in German lately in Hudson, but I understand very   
> little German.

I've seen that, too, now and then. It's not intended, and likely to be
a configuration issue or a global OS setting that somehow gets
heeded now. Perhaps Mike can shed some light on this if he can spare
some minutes...

> It looks like cvs/gcc is moving?
> ?Or all of cm3/cvs?

I'm not sure what you are hinting at with that.
I don't know of any move, nor have I heard anything new of the git/hg
front work.

> e.g.:   
> http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console
>
> http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console

These are examples of German texts I assume...
We'll try to fix that, but it's low priority.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Wed Oct 27 10:22:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 08:22:55 +0000
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
In-Reply-To: <20101027100409.3807ovva8gs80os4@mail.elegosoft.com>
References: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>,
	<20101027100409.3807ovva8gs80os4@mail.elegosoft.com>
Message-ID: <COL101-W7401FFDF127168A912361E6430@phx.gbl>


> > I'm experimenting with using Amazon Web Services though.
> I haven't tried that yet; but if you want to set up a test node there,
> that would be welcome.


It's gotten further. Below.


> > It looks like cvs/gcc is moving?
> >  Or all of cm3/cvs?
>
> I'm not sure what you are hinting at with that.


Look at the CVS roots in hudson.
I'm seeing cm3cvs.acme-works.com.
I never saw that before tonight.


> > e.g.:
> > http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console
> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console
>
> These are examples of German texts I assume...

That too..
But: These are examples running in Amazon Web Services actually.
"jaws1" -- Jay Amazon Web Services 1


question then: what is the thinking around having multiple nodes of same "type"?
? You know..I setup a "test" node..can that coexist with a "real" node? Or only in that
? I fiddle with the jobs to be on one, run them, and then put it back if it didsn't work?
Shedule the jobs on all of them?
If they all work, purely redundant.
If some nodes down, the redundancy useful?
I could see powering off the AWS nodes for long periods to save money.
? esp. if I get NetBSD and OpenBSD running there.
? heck, it might be possible to run Darwin there. Might.
Just change the "tags" that "bind" jobs to machines, to say like linux-i386 instead of machine names xlinux, jaws1, etc.??


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed Oct 27 10:46:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 08:46:21 +0000
Subject: [M3devel] small problems bring up new node
Message-ID: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>


Olaf, bringing up new nodes I think finds small problems in the automation.


new node: jaws1 which is Linux/x86
? (Rename it if you don't like it.)

? 
initial install worked in one attempt, good:
http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/


building cm3cg worked in one attempt, good:
http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/


but building the rest failed, for lack of "last ok" build:
http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull


I'm sure if I just copy stuff around it'll work.
Unless we need to start with a newer release,
which is a different matter if so.


This node was cloned from xlinux and I just changed the node
name and node to ssh to.


(The great thing about a C backend is all this testing
across every architecture would all but disappear..)


?- Jay 		 	   		  

From wagner at elegosoft.com  Wed Oct 27 11:02:19 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 27 Oct 2010 11:02:19 +0200
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
In-Reply-To: <COL101-W7401FFDF127168A912361E6430@phx.gbl>
References: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>,
	<20101027100409.3807ovva8gs80os4@mail.elegosoft.com>
	<COL101-W7401FFDF127168A912361E6430@phx.gbl>
Message-ID: <20101027110219.q48envgsgwwg0k44@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>> > I'm experimenting with using Amazon Web Services though.
>> I haven't tried that yet; but if you want to set up a test node there,
>> that would be welcome.
>
> It's gotten further. Below.
Ah.

>> > It looks like cvs/gcc is moving?
>> >  Or all of cm3/cvs?
>>
>> I'm not sure what you are hinting at with that.
>
> Look at the CVS roots in hudson.
> I'm seeing cm3cvs.acme-works.com.
> I never saw that before tonight.

Oops, I forgot about that. That's a mirror on a virtual machine
Mike has set up; I thought I posted that to the list. Only a few
jobs use(d) it until now though. It's only a temporary solution,
though these always tend to become long-living :-)

>> > e.g.:
>> >   
>> http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console
>> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console
>>
>> These are examples of German texts I assume...
>
> That too..
> But: These are examples running in Amazon Web Services actually.
> "jaws1" -- Jay Amazon Web Services 1
>
> question then: what is the thinking around having multiple nodes of   
> same "type"?

You mean for one target platform, I assume?

> ? You know..I setup a "test" node..can that coexist with a "real"   
> node? Or only in that
> ? I fiddle with the jobs to be on one, run them, and then put it   
> back if it didsn't work?

Feel free to add test nodes as you need (not necessarily run continuous
integration on them because of the load that generates).

> Shedule the jobs on all of them?
We shouldn't actually run the same builds and tests on multiple nodes
for a longer period of time.

> If they all work, purely redundant.
> If some nodes down, the redundancy useful?

Yes, it would be great to have an automated switchover in this case.
Except for the job dependeny from build on m3cc there should be no
problem in defining a group of equivalent nodes in Hudson (that's the
provided concept).

> I could see powering off the AWS nodes for long periods to save money.
> ? esp. if I get NetBSD and OpenBSD running there.
> ? heck, it might be possible to run Darwin there. Might.
> Just change the "tags" that "bind" jobs to machines, to say like   
> linux-i386 instead of machine names xlinux, jaws1, etc.??

Yes, that's the mechanism to define groups of equivalent slave
machines. Add a unique tag to all the build nodes that may run your job
and use that in the job definition.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Wed Oct 27 11:19:49 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 27 Oct 2010 11:19:49 +0200
Subject: [M3devel] small problems bring up new node
In-Reply-To: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>
References: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>
Message-ID: <20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Olaf, bringing up new nodes I think finds small problems in the automation.
>
> new node: jaws1 which is Linux/x86
> ? (Rename it if you don't like it.)
> ?
> initial install worked in one attempt, good:
> http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/
>
> building cm3cg worked in one attempt, good:
> http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/
>
> but building the rest failed, for lack of "last ok" build:
> http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull

That hasn't been realluy automated in a generic fashion yet.
I always had to perform several steps more or less manually due to
different environments etc. If you can write a general boot or init
job that will be great.

The build and test jobs all expect valid cm3 package pool setups
in current and lastok. That at least should be easy to automate.

> I'm sure if I just copy stuff around it'll work.
> Unless we need to start with a newer release,
> which is a different matter if so.
>
> This node was cloned from xlinux and I just changed the node
> name and node to ssh to.

There are different variants of init jobs for different platforms.
Maybe you just were unlucky to pick a rather old one :-/

> (The great thing about a C backend is all this testing
> across every architecture would all but disappear..)

No, it wouldn't. We could neither be sure that the generated C code
compiles with a native compiler (unless we require the same version
of gcc everywhere) nor that it would perform in the same way on all
platforms. That doesn't mean that a C backend wouldn't be a great
extension, of course.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Wed Oct 27 11:28:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 09:28:14 +0000
Subject: [M3devel] small problems bring up new node
In-Reply-To: <20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>
References: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>,
	<20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>
Message-ID: <COL101-W53C69CA2CF01060D50A5EBE6430@phx.gbl>


Hm. I think most of the code is outside of Hudson by now, but I'll poke around.


We would generate highly portable C/C++.
We wouldn't depend on gcc. gcc just isn't, in my experience, so much better/different
than any other C/C++ compiler -- partly because I mostly use Microsoft Visual C++ and
that compiler has fairly few extensions. Perhaps if I used gcc more I'd be lulled into using
its many unique extensions.
#ifdef linux would generally suffice for Linux on all processors.
? No need for the ppc/sparc/etc. machines.
#ifdef freebsd ditto.
? No need for the ppc/sparc/etc. machines.
As well, autoconf might subsume some of that.

We might still try to have some 32bit and 64bit machines, some sparc, mips, etc., but
? no need for the full cross product.


endian and wordsize would be separate factors
We may or may not need to know them statically.
i.e. we would either typedef integer like in m3core.h, or use autoconf.


I think if m3cg had a notion of a field reference, the front end would no longer
care about endian. I think it only uses it to layout bitfields within bytes/integers.
Heck -- given that we have no bitfields used between C and Modula-3, I think this
dependency can be removed already, just do the layout arbitrarily!


?- Jay


----------------------------------------
> Date: Wed, 27 Oct 2010 11:19:49 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] small problems bring up new node
>
> Quoting Jay K :
>
> > Olaf, bringing up new nodes I think finds small problems in the automation.
> >
> > new node: jaws1 which is Linux/x86
> >   (Rename it if you don't like it.)
> >
> > initial install worked in one attempt, good:
> > http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/
> >
> > building cm3cg worked in one attempt, good:
> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/
> >
> > but building the rest failed, for lack of "last ok" build:
> > http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull
>
> That hasn't been realluy automated in a generic fashion yet.
> I always had to perform several steps more or less manually due to
> different environments etc. If you can write a general boot or init
> job that will be great.
>
> The build and test jobs all expect valid cm3 package pool setups
> in current and lastok. That at least should be easy to automate.
>
> > I'm sure if I just copy stuff around it'll work.
> > Unless we need to start with a newer release,
> > which is a different matter if so.
> >
> > This node was cloned from xlinux and I just changed the node
> > name and node to ssh to.
>
> There are different variants of init jobs for different platforms.
> Maybe you just were unlucky to pick a rather old one :-/
>
> > (The great thing about a C backend is all this testing
> > across every architecture would all but disappear..)
>
> No, it wouldn't. We could neither be sure that the generated C code
> compiles with a native compiler (unless we require the same version
> of gcc everywhere) nor that it would perform in the same way on all
> platforms. That doesn't mean that a C backend wouldn't be a great
> extension, of course.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From dragisha at m3w.org  Wed Oct 27 23:41:19 2010
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 27 Oct 2010 23:41:19 +0200
Subject: [M3devel] small problems bring up new node (autoconf????)
In-Reply-To: <COL101-W53C69CA2CF01060D50A5EBE6430@phx.gbl>
References: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>,
	<20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>
	<COL101-W53C69CA2CF01060D50A5EBE6430@phx.gbl>
Message-ID: <A485C743-B052-4BB1-9E44-EF13F47B871D@m3w.org>

Autoconf will be used in future cm3????

On Oct 27, 2010, at 11:28 AM, Jay K wrote:

> As well, autoconf might subsume some of that.



From wagner at elegosoft.com  Fri Oct 29 14:11:34 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 29 Oct 2010 14:11:34 +0200
Subject: [M3devel] recent cm3cg regression
Message-ID: <20101029141134.7gx4toby80w4k0gs@mail.elegosoft.com>

recent m3cc changes lead to lots of compilation errors, e.g.

http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-AMD64_FREEBSD/133/console

please fix

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Oct 29 21:16:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 29 Oct 2010 19:16:21 +0000
Subject: [M3devel] recent cm3cg regression
In-Reply-To: <20101029141134.7gx4toby80w4k0gs@mail.elegosoft.com>
References: <20101029141134.7gx4toby80w4k0gs@mail.elegosoft.com>
Message-ID: <COL101-W20AC67BB0B46D76B4C3BA4E6450@phx.gbl>


oops sorry I forgot to commit m3gty45.h.

?- Jay



----------------------------------------
> Date: Fri, 29 Oct 2010 14:11:34 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] recent cm3cg regression
>
> recent m3cc changes lead to lots of compilation errors, e.g.
>
> http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-AMD64_FREEBSD/133/console
>
> please fix
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From jay.krell at cornell.edu  Sun Oct 31 05:43:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 04:43:59 +0000
Subject: [M3devel] "looping to get all types declared first"
Message-ID: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>


There is this "replay" thing I put in the backend.
It isn't quite right.
 
 
I would like to have multiple passes, where if
all the types haven't been declared yet, non-type-declaration
operations do nothing.
 
There are approximately three approaches.
 
 1) the frontend front-loads all type declarations
so as soon as non-type declaration seen, that is the end,
ok to loop; I don't know if this is true.
 
 
 2) in each operand implementation, check if all the types
  have been declared yet and if not and if the operation
  isn't a declaration, immediately return
  This isn't entirely true. Some things like begin unit/procedure/block
  need to do anything, to track lexical location for building
  prefixes on type names, or somesuch.
 
 Actually, I think all the type data structures might need
to be in a linked list going from inner scope to outer scope
and searches have to search them in order and take the first hit. ?
 
 
 3) or, similarly, but the question is, do we loop
  over the serialized form, or do we first deserialize
  into an in-memory form, and then loop over that?
 
 
Those are my main questions:
   a) does the front end front-load declarations? I can trace a bit in cm3cg and guess.
   b) if not, do people prefer multiple passes over the serialized form or
   first deserialize into an in-memory form, and then loop over that
   c) change frontend to front-load declarations
 
 
My preference is b.
It is isn't the most efficient, but the efficiency should be plenty adequate.
 
 
I understand typeids are hashes, so scope is sort of irrelevant.
But typenames specifically are scoped.
 
 
 - Jay 		 	   		  

From jay.krell at cornell.edu  Sun Oct 31 08:20:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 07:20:37 +0000
Subject: [M3devel] va/loophole/integers
Message-ID: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>


When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.


I think this is wrong in multiple ways.


For 64bit targets, nothing should be done.
Backend can check that it is given equal types.
This might already be done.


A range check should be done.
Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.
Code that wants to ignore this can..well..it takes a bit if code I guess, but still.

Similarly for LONGCARD to CARDINAL

And then, still, I don't think loophole is appropriate.

Perhaps loophole in backend isn't meant to match up to loophole in the language?
I guess, maybe, but this seems...not intuitive.

In particular I tried making loophole use VIEW_CONVERT and I was look at the
affect here:

libm3/.../FilePosix.m3

PROCEDURE RegularFileSeek(
??? h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
? : INTEGER RAISES {OSError.E} =
? BEGIN
??? WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
????? IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
????? RETURN VAL(result, INTEGER)
??? END
? END RegularFileSeek;



(1034) call_direct procedure:Unix__lseek type:int64
(1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
(1036) store var:noname offset:0 src_t:int64 dst_t:int64
(1037) begin_block
(1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
(1039) load var:noname offset:0 src_t:int64 dst_t:int64
(1040) store var:result offset:0 src_t:int64 dst_t:int64
(1041) set_source_line 0x96(150)
(1042) load_integer type:int32 0
(1043) loophole type1:int32 type2:int64



and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.


Probably the backend should check that loophole is using two equal sized types, and then use view convert.
Though for now at least it has to deal with these integer conversions.


?- Jay

 		 	   		  

From hosking at cs.purdue.edu  Sun Oct 31 17:48:58 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 31 Oct 2010 12:48:58 -0400
Subject: [M3devel] "looping to get all types declared first"
In-Reply-To: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>
References: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>
Message-ID: <98707534-E63B-414E-BD43-508BB9A2C3D0@cs.purdue.edu>

I don't understand the purpose of all this.  Can't you just maintain one global table mapping type id to type?

On Oct 31, 2010, at 12:43 AM, Jay K wrote:

> 
> There is this "replay" thing I put in the backend.
> It isn't quite right.
> 
> 
> I would like to have multiple passes, where if
> all the types haven't been declared yet, non-type-declaration
> operations do nothing.
> 
> There are approximately three approaches.
> 
> 1) the frontend front-loads all type declarations
> so as soon as non-type declaration seen, that is the end,
> ok to loop; I don't know if this is true.
> 
> 
> 2) in each operand implementation, check if all the types
>  have been declared yet and if not and if the operation
>  isn't a declaration, immediately return
>  This isn't entirely true. Some things like begin unit/procedure/block
>  need to do anything, to track lexical location for building
>  prefixes on type names, or somesuch.
> 
> Actually, I think all the type data structures might need
> to be in a linked list going from inner scope to outer scope
> and searches have to search them in order and take the first hit. ?
> 
> 
> 3) or, similarly, but the question is, do we loop
>  over the serialized form, or do we first deserialize
>  into an in-memory form, and then loop over that?
> 
> 
> Those are my main questions:
>   a) does the front end front-load declarations? I can trace a bit in cm3cg and guess.
>   b) if not, do people prefer multiple passes over the serialized form or
>   first deserialize into an in-memory form, and then loop over that
>   c) change frontend to front-load declarations
> 
> 
> My preference is b.
> It is isn't the most efficient, but the efficiency should be plenty adequate.
> 
> 
> I understand typeids are hashes, so scope is sort of irrelevant.
> But typenames specifically are scoped.
> 
> 
> - Jay 		 	   		  



From hosking at cs.purdue.edu  Sun Oct 31 18:51:14 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 31 Oct 2010 13:51:14 -0400
Subject: [M3devel] va/loophole/integers
In-Reply-To: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>
References: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>
Message-ID: <3D7DC9AE-0089-48AE-BA7D-6DB07BDD1F85@cs.purdue.edu>

On Oct 31, 2010, at 3:20 AM, Jay K wrote:

> When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.

Possibly.  LOOPHOLE in the language expects values with equal BITSIZE.  I used it originally because LOOPHOLE as implemented seemed to do the right thing.  Probably we should use widen/chop (as defined in M3CG_Ops.i3).

> I think this is wrong in multiple ways.
> 
> 
> For 64bit targets, nothing should be done.
> Backend can check that it is given equal types.
> This might already be done.

If they are same BITSIZE then loophole is appropriate, no?

> A range check should be done.

We have a range check in VAL:

      Expr.GetBounds (ce.args[0], minu, maxu);
      EVAL Type.GetBounds (t, mint, maxt);
      IF TInt.LT (minu, mint) THEN
        (* we need a lower bound check *)
        IF TInt.LT (maxt, maxu) THEN
          (* we also need an upper bound check *)
          ce.args[0] := CheckExpr.New (ce.args[0], mint, maxt,
                                          CG.RuntimeError.ValueOutOfRange);
          Expr.TypeCheck (ce.args[0], cs);
        ELSE
          ce.args[0] := CheckExpr.NewLower (ce.args[0], mint,
                                          CG.RuntimeError.ValueOutOfRange);
          Expr.TypeCheck (ce.args[0], cs);
        END;
      ELSIF TInt.LT (maxt, maxu) THEN
        (* we need an upper bound check *)
        ce.args[0] := CheckExpr.NewUpper (ce.args[0], maxt,
                                          CG.RuntimeError.ValueOutOfRange);
        Expr.TypeCheck (ce.args[0], cs);
      END;


> Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.

This *will* raise an exception if it doesn't fit.

> Code that wants to ignore this can..well..it takes a bit if code I guess, but still.
> Similarly for LONGCARD to CARDINAL

Should be the same.

> And then, still, I don't think loophole is appropriate.
> 
> Perhaps loophole in backend isn't meant to match up to loophole in the language?
> I guess, maybe, but this seems...not intuitive.

Perhaps we should use widen/chop?

> In particular I tried making loophole use VIEW_CONVERT and I was look at the
> affect here:
> 
> libm3/.../FilePosix.m3
> 
> PROCEDURE RegularFileSeek(
>     h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
>   : INTEGER RAISES {OSError.E} =
>   BEGIN
>     WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
>       IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
>       RETURN VAL(result, INTEGER)
>     END
>   END RegularFileSeek;
> 
> 
> 
> (1034) call_direct procedure:Unix__lseek type:int64
> (1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
> (1036) store var:noname offset:0 src_t:int64 dst_t:int64
> (1037) begin_block
> (1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
> (1039) load var:noname offset:0 src_t:int64 dst_t:int64
> (1040) store var:result offset:0 src_t:int64 dst_t:int64
> (1041) set_source_line 0x96(150)
> (1042) load_integer type:int32 0
> (1043) loophole type1:int32 type2:int64
> 
> 
> 
> and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.
> 
> 
> Probably the backend should check that loophole is using two equal sized types, and then use view convert.
> Though for now at least it has to deal with these integer conversions.
> 
> 
>  - Jay
> 
> 		 	   		  



From jay.krell at cornell.edu  Sun Oct 31 21:50:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 20:50:14 +0000
Subject: [M3devel] va/loophole/integers
In-Reply-To: <3D7DC9AE-0089-48AE-BA7D-6DB07BDD1F85@cs.purdue.edu>
References: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>,
	<3D7DC9AE-0089-48AE-BA7D-6DB07BDD1F85@cs.purdue.edu>
Message-ID: <COL101-W1960B31CCD5A3F3A1CF8EE6470@phx.gbl>


I admit I didn't read all the code or try a test -- so the range check could be there already, yes.

?> LOOPHOLE in the language expects values with equal BITSIZE

Ok. So the assert I added is redundant, but that's ok, asserts usually are.

> Perhaps we should use widen/chop?

Sounds promising.

I admit I'm just not sure. The current code doesn't seem terrible.
General pattern: Lots of things are surprising (not intuitive) when first discovered.
But that doesn't make them wrong or unreasonable.

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sun, 31 Oct 2010 13:51:14 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] va/loophole/integers
>
> On Oct 31, 2010, at 3:20 AM, Jay K wrote:
>
> > When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.
>
> Possibly. LOOPHOLE in the language expects values with equal BITSIZE. I used it originally because LOOPHOLE as implemented seemed to do the right thing. Probably we should use widen/chop (as defined in M3CG_Ops.i3).
>
> > I think this is wrong in multiple ways.
> >
> >
> > For 64bit targets, nothing should be done.
> > Backend can check that it is given equal types.
> > This might already be done.
>
> If they are same BITSIZE then loophole is appropriate, no?
>
> > A range check should be done.
>
> We have a range check in VAL:
>
> Expr.GetBounds (ce.args[0], minu, maxu);
> EVAL Type.GetBounds (t, mint, maxt);
> IF TInt.LT (minu, mint) THEN
> (* we need a lower bound check *)
> IF TInt.LT (maxt, maxu) THEN
> (* we also need an upper bound check *)
> ce.args[0] := CheckExpr.New (ce.args[0], mint, maxt,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> ELSE
> ce.args[0] := CheckExpr.NewLower (ce.args[0], mint,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> END;
> ELSIF TInt.LT (maxt, maxu) THEN
> (* we need an upper bound check *)
> ce.args[0] := CheckExpr.NewUpper (ce.args[0], maxt,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> END;
>
>
> > Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.
>
> This *will* raise an exception if it doesn't fit.
>
> > Code that wants to ignore this can..well..it takes a bit if code I guess, but still.
> > Similarly for LONGCARD to CARDINAL
>
> Should be the same.
>
> > And then, still, I don't think loophole is appropriate.
> >
> > Perhaps loophole in backend isn't meant to match up to loophole in the language?
> > I guess, maybe, but this seems...not intuitive.
>
> Perhaps we should use widen/chop?
>
> > In particular I tried making loophole use VIEW_CONVERT and I was look at the
> > affect here:
> >
> > libm3/.../FilePosix.m3
> >
> > PROCEDURE RegularFileSeek(
> > h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
> > : INTEGER RAISES {OSError.E} =
> > BEGIN
> > WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
> > IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
> > RETURN VAL(result, INTEGER)
> > END
> > END RegularFileSeek;
> >
> >
> >
> > (1034) call_direct procedure:Unix__lseek type:int64
> > (1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
> > (1036) store var:noname offset:0 src_t:int64 dst_t:int64
> > (1037) begin_block
> > (1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
> > (1039) load var:noname offset:0 src_t:int64 dst_t:int64
> > (1040) store var:result offset:0 src_t:int64 dst_t:int64
> > (1041) set_source_line 0x96(150)
> > (1042) load_integer type:int32 0
> > (1043) loophole type1:int32 type2:int64
> >
> >
> >
> > and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.
> >
> >
> > Probably the backend should check that loophole is using two equal sized types, and then use view convert.
> > Though for now at least it has to deal with these integer conversions.
> >
> >
> > - Jay
> >
> >
>
 		 	   		  

From jay.krell at cornell.edu  Sun Oct 31 21:54:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 20:54:34 +0000
Subject: [M3devel] "looping to get all types declared first"
In-Reply-To: <98707534-E63B-414E-BD43-508BB9A2C3D0@cs.purdue.edu>
References: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>,
	<98707534-E63B-414E-BD43-508BB9A2C3D0@cs.purdue.edu>
Message-ID: <COL101-W13EDB0642C9A0A6E24EE88E6470@phx.gbl>


> I don't understand the purpose of all this. Can't you just maintain one global table mapping type id to type?

The general problem is that types are used before they are declared.
Another problem is my ignorance of what is possible.

For example, is it possible to just no type on everything at first, just a struct lang_type with typeid,
and then walk the gcc trees repeatedly replacing those as possible?

Would that require, perhaps, setting unit_at_a_time = true, which is an optimization, but ok?

Or do all the types need to be correct upon initial tree construction?

If they have to be correct up front, it takes multiple passes through the type declarations due to
circularities or out-of-orders.

I have something in place for multiple passes, but it doesn't avoid building statements (non-declarations)
in the earlier passes.

Typenames are not amenable to one global table, but I'm not sure they matter at all.
I'm thinking the backend can basically ignore them entirely -- or at least not do anything new with them
in this effort to make the trees correctly typed.


?- Jay
 		 	   		  

From dragisha at m3w.org  Fri Oct  1 00:40:17 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 01 Oct 2010 00:40:17 +0200
Subject: [M3devel] Windows... cm3... linking...
In-Reply-To: <1285879260.3196.2.camel@boromir.m3w.org>
References: <1285879260.3196.2.camel@boromir.m3w.org>
Message-ID: <1285886417.3196.5.camel@boromir.m3w.org>

Got through this... phew... :)

As I am using Shining Light OpenSSL-Win32 port, I jad to get through
with options... Pretty obvious except part where if \\ used
in /LIBPATH:, openssl lib compiles and ships but client apps does not -
there is no \ in sight.

Solution is - even when making m3makefile for Win32 - use / as path
separator.

On Thu, 2010-09-30 at 22:41 +0200, Dragi?a Duri? wrote:
> Anybody doing this? What is m3makefile "magic" for it?

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  1 02:23:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 00:23:50 +0000
Subject: [M3devel] Windows... cm3... linking...
In-Reply-To: <1285886417.3196.5.camel@boromir.m3w.org>
References: <1285879260.3196.2.camel@boromir.m3w.org>,
	<1285886417.3196.5.camel@boromir.m3w.org>
Message-ID: <COL101-W4764E31E9BC2F7341C98D1E6690@phx.gbl>


Your original question was very unclear.
 
 - Jay


----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Fri, 1 Oct 2010 00:40:17 +0200
> Subject: Re: [M3devel] Windows... cm3... linking...
>
> Got through this... phew... :)
>
> As I am using Shining Light OpenSSL-Win32 port, I jad to get through
> with options... Pretty obvious except part where if \\ used
> in /LIBPATH:, openssl lib compiles and ships but client apps does not -
> there is no \ in sight.
>
> Solution is - even when making m3makefile for Win32 - use / as path
> separator.
>
> On Thu, 2010-09-30 at 22:41 +0200, Dragi?a Duri? wrote:
> > Anybody doing this? What is m3makefile "magic" for it?
>
> --
> Dragi?a Duri? 
> 		 	   		  

From jay.krell at cornell.edu  Fri Oct  1 12:17:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 10:17:23 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
Message-ID: <COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>


Huh? You mean hack, cross once, unhack?
I want to cross build as a regular occurence. The entire system.
I already do actually. But currently only enough to get cm3.
The problems occur if you try to build the entire system.
? Ok, right, I left one of the hacks in actually.
? Like TEXTs have a 2GB size limit or such.


"Regular" cross builds are normal in other environments these days.


?- Jay

----------------------------------------
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
> From: hosking at cs.purdue.edu
> Date: Thu, 30 Sep 2010 09:42:59 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> Whenever you cross build you should do a subsequent native bootstrap to eliminate those.
>
> On 30 Sep 2010, at 07:14, Jay K wrote:
>
> >
> > So..we can't fully cross build a 64bit target from a 32bit host because some code
> > wants to declare arrays that fill memory, like so that indexing them never fails
> > an overflow check:
> >
> >
> > TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example
> >
> >
> > I'm faced with a few choices:
> > - do nothing
> > - have the front end pin the sizes to its maximum
> > Leading to such code to fail if it actually operates on data larger than 2GB
> > - use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less
> > - use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long",
> > (roughly: "long" suffices instead on most 64bit systems)
> > - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c
> >
> >
> > Extremely similarly btw:
> >
> >
> > TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example
> > TYPE T2 = RECORD a,b,c:T1; END;
> >
> >
> > which is just to say, it isn't just about total array sizes, but also field offsets.
> >
> >
> > (I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...)
> >
> >
> >
> > I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code.
> > e.g. m3front/src/types/Type.i3/Info, and then all its users.
> >
> > Should these types use a different and unsafe form?
> > Do we have a convenient unsafe form?
> >
> > - Jay
> >
>
 		 	   		  

From jay.krell at cornell.edu  Fri Oct  1 12:19:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 10:19:35 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <1285845869.2729.7.camel@boromir.m3w.org>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<1285845869.2729.7.camel@boromir.m3w.org>
Message-ID: <COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>


Really? What technique was employed?
The current system doesn't work as I want. As most other compilers now do.
You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
Right. In the past gcc didn't have such good cross building capabilities.
So that might have helped.
Now it does. Now cm3cg has no problem crossing arbitrarily.
But the cm3 frontend does.
A 32bit cm3 frontend can't handle sizes larger than 4GB.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 30 Sep 2010 13:24:29 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>
> I went this route a decade or so ago... When I was porting pm3 to
> Linux/ALPHA... John Polstra employed same technique later for ezm3...
>
> Standard bootstrap process splits build process at assembly level. For
> Windows it is split at object code level.
>
> What I did was to split it ad GCC "IR" level. that way, 32->64 bit
> crosscompiler was never required.
>
> On Thu, 2010-09-30 at 11:14 +0000, Jay K wrote:
> > So..we can't fully cross build a 64bit target from a 32bit host
> > because some code
> > wants to declare arrays that fill memory, like so that indexing them
> > never fails
> > an overflow check:
> >
> >
> >
> --
> Dragi?a Duri? 
>
 		 	   		  

From wagner at elegosoft.com  Fri Oct  1 12:37:23 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Oct 2010 12:37:23 +0200
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<1285845869.2729.7.camel@boromir.m3w.org>
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>
Message-ID: <20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>
> Really? What technique was employed?
> The current system doesn't work as I want. As most other compilers now do.
> You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
> Right. In the past gcc didn't have such good cross building capabilities.
> So that might have helped.
> Now it does. Now cm3cg has no problem crossing arbitrarily.
> But the cm3 frontend does.
> A 32bit cm3 frontend can't handle sizes larger than 4GB.

Is this really still such an important problem?
We can easily support cross-builds from all 32 bit targets to all
32 bit targets and from 64 bit targets to both 32 and 64 bit targets,
right?

And we do have several 64 bit build machines...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Oct  1 12:46:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 10:46:12 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>, ,
	<1285845869.2729.7.camel@boromir.m3w.org>,
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>,
	<20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
Message-ID: <COL101-W354E7D14E90E16D1BA3F77E6690@phx.gbl>


No, it isn't a big problem, but it is an obvious wart. I'd like to fix it. I know how. It is just "a bit" tedious.
It is common these days to support arbitrary crosses.
I think we should.

However, granted, gcc uses a mix of:
? 64bit long (for 64bit host targeting 64bit)
? 64bit long long (32bit host targeting 64bit) -- easy, esp. in C where long => long long conversion is automatic (given that it is lossless, no problem, imho, but I lost that argument here, meanwhile, most code in the world is written this way and nobody complains...) 
? "double_int" a struct containing two longs (I don't know why they still use this, maybe support 32bit host targeting 64bit without a 64bit long long?)
? gmp -- arbitrary precision (ditto) 

If we "just" use LONGINT more instead of INTEGER, we can get by with less change.
The "more honest" approach is to use Target.Int though.

I'd like to take a stab at it, but I expect it might be invasive, want to make sure it is ok.

?- Jay

----------------------------------------
> Date: Fri, 1 Oct 2010 12:37:23 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>
> Quoting Jay K :
>
> >
> > Really? What technique was employed?
> > The current system doesn't work as I want. As most other compilers now do.
> > You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
> > Right. In the past gcc didn't have such good cross building capabilities.
> > So that might have helped.
> > Now it does. Now cm3cg has no problem crossing arbitrarily.
> > But the cm3 frontend does.
> > A 32bit cm3 frontend can't handle sizes larger than 4GB.
>
> Is this really still such an important problem?
> We can easily support cross-builds from all 32 bit targets to all
> 32 bit targets and from 64 bit targets to both 32 and 64 bit targets,
> right?
>
> And we do have several 64 bit build machines...
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  1 13:17:16 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 01 Oct 2010 13:17:16 +0200
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>
	, <12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
	<COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
Message-ID: <1285931836.14463.20.camel@boromir.m3w.org>

Can we cross-develop on regular basis now?

For example, I would like to develop for Android (what happened with
it?) and just upload packages.

Possible?

On Fri, 2010-10-01 at 10:17 +0000, Jay K wrote:
> Huh? You mean hack, cross once, unhack?
> I want to cross build as a regular occurence. The entire system.
> I already do actually. But currently only enough to get cm3.
> The problems occur if you try to build the entire system.
>   Ok, right, I left one of the hacks in actually.
>   Like TEXTs have a 2GB size limit or such. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  1 13:30:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 1 Oct 2010 11:30:52 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <1285931836.14463.20.camel@boromir.m3w.org>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,,
	<12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>,
	<COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>,
	<1285931836.14463.20.camel@boromir.m3w.org>
Message-ID: <COL101-W631D593E96E1992F179786E6690@phx.gbl>


Yes and no. For most people's point of view, no.


I regularly cross build just enough to build cm3 -- m3core/libm3/m3quake/cm3/m3middle/m3front/m3linker.


The missing pieces:
? - you can't the entire system, there are a small number of errors
? - What this is doing is getting as far as generating assembly source.
?? Assemble, compiler C (including having C library headers), link C (including having C libraries) are left
? as an exercise, and is of varying difficulty.


If you want to cross to Linux, then it isn't too difficult. But I haven't done it much.
If you want to cross to mingw or cygwin it probably isn't too difficult.
If you want to cross to NetBSD, it probably isn't too difficult.
But all these "isn't too difficult" aren't necessarily the same.


The problem is needing a cross C compiler, cross assembler, cross linker, C libraries and C headers.
A cross C compiler that only generates assembly is as easy as Modula-3 -- use gcc.
Cross assembler and linker can often but not always be GNU binutils.
C libraries and C headers can be glibc or newlib or uclibc, shouldn't be too difficult.
For other systems, you copy /usr/lib and /usr/include.
? I have cross compiled to Solaris from Cygwin for example, and from something (I forgot) to Irix I think.
? I have a cross compiler for alpha-vms on my Mac. But finding the headers/libraries was a bit challenging.


On the other hand, on systems like Fedora, Gentoo, Debian, people are somewhat busy as I understand providing
prebuilt cross toolset packages, apt-get install whatever.


As well for iPhone and Android the "native" toolsets are cross.
So these should be easy.


Android looked a bit daunting to get started with though.
I haven't so much as done hello world in Java or C running in an emulator or on hardware.
If someone can walk me through hello world in C running in an emulator, I'd be in a better position to get Modula-3 there.


I also find anything that involves Eclipse daunting. There are too many to choise from, and while I like
that they have an install-free option, it is nice to have an installer when first starting out.



Now then, there is the question of what should Modula-3 distribution format be?
I think the 3.6 format is a good model to strive for.
Distribute a bunch of assembly files and assemble, compile C, link, on the target.
That equates to "useful to just Jay" becoming more useful.
However Olaf's point is valid. We'd need just one 64bit host to cross build all the 64bit distributions.
And there is other work needed to make this so.
?Mainly some scripting to package stuff up.
? Actually Olaf's "workspace" packages might be close to it. But I really don't like there
? being cm3-ws-web, cm3-ws-games, cm3-ws-comm, etc. Too many. Confusing.
?I want just one cm3-target.tar.gz, and I want the web page to sniff my browser
? and point me at the right one (like Firefox download does). Really, I find our
? download pages very hard to wade through. Huge lists of stuff to download.

Anyway.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 1 Oct 2010 13:17:16 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>
> Can we cross-develop on regular basis now?
>
> For example, I would like to develop for Android (what happened with
> it?) and just upload packages.
>
> Possible?
>
> On Fri, 2010-10-01 at 10:17 +0000, Jay K wrote:
> > Huh? You mean hack, cross once, unhack?
> > I want to cross build as a regular occurence. The entire system.
> > I already do actually. But currently only enough to get cm3.
> > The problems occur if you try to build the entire system.
> > Ok, right, I left one of the hacks in actually.
> > Like TEXTs have a 2GB size limit or such.
> --
> Dragi?a Duri? 
>
 		 	   		  

From hosking at cs.purdue.edu  Fri Oct  1 15:59:22 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Oct 2010 09:59:22 -0400
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W354E7D14E90E16D1BA3F77E6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>, ,
	<1285845869.2729.7.camel@boromir.m3w.org>,
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>,
	<20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
	<COL101-W354E7D14E90E16D1BA3F77E6690@phx.gbl>
Message-ID: <8EAB461C-8FA1-4D6A-864D-B810029D5561@cs.purdue.edu>

I don't think this should be a priority, especially if invasive...

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 1 Oct 2010, at 06:46, Jay K wrote:

> 
> No, it isn't a big problem, but it is an obvious wart. I'd like to fix it. I know how. It is just "a bit" tedious.
> It is common these days to support arbitrary crosses.
> I think we should.
> 
> However, granted, gcc uses a mix of:
>   64bit long (for 64bit host targeting 64bit)
>   64bit long long (32bit host targeting 64bit) -- easy, esp. in C where long => long long conversion is automatic (given that it is lossless, no problem, imho, but I lost that argument here, meanwhile, most code in the world is written this way and nobody complains...) 
>   "double_int" a struct containing two longs (I don't know why they still use this, maybe support 32bit host targeting 64bit without a 64bit long long?)
>   gmp -- arbitrary precision (ditto) 
> 
> If we "just" use LONGINT more instead of INTEGER, we can get by with less change.
> The "more honest" approach is to use Target.Int though.
> 
> I'd like to take a stab at it, but I expect it might be invasive, want to make sure it is ok.
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Fri, 1 Oct 2010 12:37:23 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>> 
>> Quoting Jay K :
>> 
>>> 
>>> Really? What technique was employed?
>>> The current system doesn't work as I want. As most other compilers now do.
>>> You mean maybe the .mc files were saved, copied, and cm3cg run on Alpha?
>>> Right. In the past gcc didn't have such good cross building capabilities.
>>> So that might have helped.
>>> Now it does. Now cm3cg has no problem crossing arbitrarily.
>>> But the cm3 frontend does.
>>> A 32bit cm3 frontend can't handle sizes larger than 4GB.
>> 
>> Is this really still such an important problem?
>> We can easily support cross-builds from all 32 bit targets to all
>> 32 bit targets and from 64 bit targets to both 32 and 64 bit targets,
>> right?
>> 
>> And we do have several 64 bit build machines...
>> 
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> 
> 		 	   		  

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

From hosking at cs.purdue.edu  Fri Oct  1 15:58:36 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 1 Oct 2010 09:58:36 -0400
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>,
	<12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu>
	<COL101-W5963145FD413DCE5DE4C00E6690@phx.gbl>
Message-ID: <96B9F209-182F-4422-AC77-ED4071EEAF2E@cs.purdue.edu>

What hack?
Why build the entire system in cross?  That seems overly complicated.  Better to just cross-build the compiler.

On 1 Oct 2010, at 06:17, Jay K wrote:

> 
> Huh? You mean hack, cross once, unhack?
> I want to cross build as a regular occurence. The entire system.
> I already do actually. But currently only enough to get cm3.
> The problems occur if you try to build the entire system.
>   Ok, right, I left one of the hacks in actually.
>   Like TEXTs have a 2GB size limit or such.
> 
> 
> "Regular" cross builds are normal in other environments these days.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> Subject: Re: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
>> From: hosking at cs.purdue.edu
>> Date: Thu, 30 Sep 2010 09:42:59 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> Whenever you cross build you should do a subsequent native bootstrap to eliminate those.
>> 
>> On 30 Sep 2010, at 07:14, Jay K wrote:
>> 
>>> 
>>> So..we can't fully cross build a 64bit target from a 32bit host because some code
>>> wants to declare arrays that fill memory, like so that indexing them never fails
>>> an overflow check:
>>> 
>>> 
>>> TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example
>>> 
>>> 
>>> I'm faced with a few choices:
>>> - do nothing
>>> - have the front end pin the sizes to its maximum
>>> Leading to such code to fail if it actually operates on data larger than 2GB
>>> - use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less
>>> - use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long",
>>> (roughly: "long" suffices instead on most 64bit systems)
>>> - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c
>>> 
>>> 
>>> Extremely similarly btw:
>>> 
>>> 
>>> TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example
>>> TYPE T2 = RECORD a,b,c:T1; END;
>>> 
>>> 
>>> which is just to say, it isn't just about total array sizes, but also field offsets.
>>> 
>>> 
>>> (I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...)
>>> 
>>> 
>>> 
>>> I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code.
>>> e.g. m3front/src/types/Type.i3/Info, and then all its users.
>>> 
>>> Should these types use a different and unsafe form?
>>> Do we have a convenient unsafe form?
>>> 
>>> - Jay
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Sun Oct  3 09:00:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 07:00:48 +0000
Subject: [M3devel] declare_constant
Message-ID: <COL101-W58C4E09C2D757EA99ABC2FE66B0@phx.gbl>


The frontend never calls declare_constant.
I wonder if it should be removed.
Presumably all constants are embedded in segments.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Sun Oct  3 10:00:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 08:00:07 +0000
Subject: [M3devel] unnecessary temporaries in m3cc/parse.c
Message-ID: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>


I fail to understand why the following need explicit temporaries:

check_nil
check_lo
check_hi
check_range
check_eq
shift
rotate

probably even:
? round
? floor
? ceiling

but floating point doesn't matter so much.

"stabilize_reference" can be used to avoid recomputing values.

?- Jay
 		 	   		  

From dragisha at m3w.org  Sun Oct  3 11:35:01 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 03 Oct 2010 11:35:01 +0200
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20101003073802.D04B02474003@birch.elegosoft.com>
References: <20101003073802.D04B02474003@birch.elegosoft.com>
Message-ID: <1286098501.14463.74.camel@boromir.m3w.org>

new source -> compiling PickleStubs.m3
../src/pickle/ver2/PickleStubs.m3: In function 'PickleStubs_M3':
../src/pickle/ver2/PickleStubs.m3:599:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3542
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
  m3_backend => 4
m3cc (aka cm3cg) failed compiling: PickleStubs.mc


Lots of these, during ./upgrade.sh, from cvshead.

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sun Oct  3 12:57:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 10:57:29 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <1286098501.14463.74.camel@boromir.m3w.org>
References: <20101003073802.D04B02474003@birch.elegosoft.com>,
	<1286098501.14463.74.camel@boromir.m3w.org>
Message-ID: <COL101-W62DE90CD685CAA398BEAEFE66B0@phx.gbl>


ok, sorry, I'm still working on it..










----------------------------------------
> From: dragisha at m3w.org
> To: jkrell at elego.de
> Date: Sun, 3 Oct 2010 11:35:01 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> new source -> compiling PickleStubs.m3
> ../src/pickle/ver2/PickleStubs.m3: In function 'PickleStubs_M3':
> ../src/pickle/ver2/PickleStubs.m3:599:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3542
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> m3_backend => 4
> m3cc (aka cm3cg) failed compiling: PickleStubs.mc
>
>
> Lots of these, during ./upgrade.sh, from cvshead.
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Sun Oct  3 14:47:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 12:47:41 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
Message-ID: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>


It appears that due to e.g.


TYPE Pointer = REF Record;
TYPE Record = RECORD
??? Next: Pointer;
END;


it is possible for the backend to get type declarations "out of order".
? There being no "correct" order, no order without forward references.
It says declare_indirect(Pointer) before declare_record(Record).
? I'm not sure of this exact example, but it does occur.


Currently fields are implicitly within the "current" record.


I think in order to break these cycles, declare_field should contain the uid of their record.


And then we should forward declare all records.
Then indirects to them.
Then their fields.


I'm not sure that solves the general case or not though.


More generally we might want to use this pattern also for objects and proctypes.


It's also likely I can solve this in the backend alone, by running more passes
until everything is resolved.


I keep thinking to myself that I might have to build up in memory
a very faithful rendition of the m3cg calls and iterate over it,
before making the gcc trees.


?


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Sun Oct  3 14:51:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 12:51:52 +0000
Subject: [M3devel] subranges 0..-1?
Message-ID: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>


../src/Common/X.i3: In function 'X_I3':
../src/Common/X.i3:4845:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3567


? gcc_assert (min <= max);

? XClientMessageEvent = RECORD
???? type: int;
???? serial: unsigned_long;??? (* # of last request processed by server *)
???? send_event: Bool;???????? (* true if this came from a SendEvent request *)
???? display: DisplayStar;???? (* Display the event was read from *)
???? window: Window;
???? message_type: Atom;
???? format: int;
???? alignment: ARRAY [0..-1] OF long;
???? data: ARRAY [0..MAX (20 * BYTESIZE (char),
????????????????????????? MAX (10 * BYTESIZE (short),
?????????????????????????????? 5 * BYTESIZE (long))) - 1] OF char; END;


???? alignment: ARRAY [0..-1] OF long;


typedef struct {
??? int type;
??? unsigned long serial;??? /* # of last request processed by server */
??? Bool send_event;??? /* true if this came from a SendEvent request */
??? Display *display;??? /* Display the event was read from */
??? Window window;
??? Atom message_type;
??? int format;
??? union {
??? ??? char b[20];
??? ??? short s[10];
??? ??? long l[5];
??? ??? } data;
} XClientMessageEvent;



eh?


I'll remove the assert.
"Clearly"? the Modula-3 should just use an array of long though for the union?


?- Jay

 		 	   		  

From hosking at cs.purdue.edu  Sun Oct  3 23:02:07 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 3 Oct 2010 17:02:07 -0400
Subject: [M3devel] declare_constant
In-Reply-To: <COL101-W58C4E09C2D757EA99ABC2FE66B0@phx.gbl>
References: <COL101-W58C4E09C2D757EA99ABC2FE66B0@phx.gbl>
Message-ID: <02D443A4-8D02-45E2-B053-37AEFC3A0A92@cs.purdue.edu>

Or perhaps we should be declaring them...

On 3 Oct 2010, at 03:00, Jay K wrote:

> 
> The frontend never calls declare_constant.
> I wonder if it should be removed.
> Presumably all constants are embedded in segments.
> 
>  - Jay
> 
> 
> 
> 
> 		 	   		  



From hosking at cs.purdue.edu  Sun Oct  3 23:05:40 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 3 Oct 2010 17:05:40 -0400
Subject: [M3devel] unnecessary temporaries in m3cc/parse.c
In-Reply-To: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>
References: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>
Message-ID: <6074704E-AF87-43FF-AE7D-361E8A6CD47D@cs.purdue.edu>

Seems reasonable.  The reasons may be lost in the mists of time...

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 3 Oct 2010, at 04:00, Jay K wrote:

> 
> I fail to understand why the following need explicit temporaries:
> 
> check_nil
> check_lo
> check_hi
> check_range
> check_eq
> shift
> rotate
> 
> probably even:
>   round
>   floor
>   ceiling
> 
> but floating point doesn't matter so much.
> 
> "stabilize_reference" can be used to avoid recomputing values.
> 
>  - Jay
> 		 	   		  

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

From dragisha at m3w.org  Sun Oct  3 23:30:31 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 03 Oct 2010 23:30:31 +0200
Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
Message-ID: <1286141431.14463.86.camel@boromir.m3w.org>

upgrade.sh works ok, it looks like.. But during make-bin-dist-min cycle
I am seeing those:

new source -> compiling RT0.i3

 declare_pointer: missing type 0xC2DE134C

 replaying to resolve circular types (pass 1)

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Mon Oct  4 01:23:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 23:23:46 +0000
Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
In-Reply-To: <1286141431.14463.86.camel@boromir.m3w.org>
References: <1286141431.14463.86.camel@boromir.m3w.org>
Message-ID: <COL101-W27F6A2E36D944772EDB520E66B0@phx.gbl>


okok I turned them off

?- Jay



----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Sun, 3 Oct 2010 23:30:31 +0200
> Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
>
> upgrade.sh works ok, it looks like.. But during make-bin-dist-min cycle
> I am seeing those:
>
> new source -> compiling RT0.i3
>
> declare_pointer: missing type 0xC2DE134C
>
> replaying to resolve circular types (pass 1)
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 01:30:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 23:30:50 +0000
Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
In-Reply-To: <1286141431.14463.86.camel@boromir.m3w.org>
References: <1286141431.14463.86.camel@boromir.m3w.org>
Message-ID: <COL101-W3644F16E785D059BC978B9E66B0@phx.gbl>


It's great to have someone else trying this stuff!

Thanks,
?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Sun, 3 Oct 2010 23:30:31 +0200
> Subject: [M3devel] cvshead upgrade/make-bin-dist-min cycle
>
> upgrade.sh works ok, it looks like.. But during make-bin-dist-min cycle
> I am seeing those:
>
> new source -> compiling RT0.i3
>
> declare_pointer: missing type 0xC2DE134C
>
> replaying to resolve circular types (pass 1)
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 01:44:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 3 Oct 2010 23:44:02 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>
Message-ID: <COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>


I think I'll just solve this in the backend by making a few passes.
Maybe something with specific passes where early passes only pay
attention to certain opcodes, that declare types.

The new/current "replay" stuff will maybe go away.

The new/current keeping of the entire file in memory will stay
unless someone has strong evidence/argument that is shouldn't.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: backend interface vs. types vs. forward references?
> Date: Sun, 3 Oct 2010 12:47:41 +0000
>
>
> It appears that due to e.g.
>
>
> TYPE Pointer = REF Record;
> TYPE Record = RECORD
>     Next: Pointer;
> END;
>
>
> it is possible for the backend to get type declarations "out of order".
>   There being no "correct" order, no order without forward references.
> It says declare_indirect(Pointer) before declare_record(Record).
>   I'm not sure of this exact example, but it does occur.
>
>
> Currently fields are implicitly within the "current" record.
>
>
> I think in order to break these cycles, declare_field should contain the uid of their record.
>
>
> And then we should forward declare all records.
> Then indirects to them.
> Then their fields.
>
>
> I'm not sure that solves the general case or not though.
>
>
> More generally we might want to use this pattern also for objects and proctypes.
>
>
> It's also likely I can solve this in the backend alone, by running more passes
> until everything is resolved.
>
>
> I keep thinking to myself that I might have to build up in memory
> a very faithful rendition of the m3cg calls and iterate over it,
> before making the gcc trees.
>
>
> ?
>
>
>  - Jay
>
>
 		 	   		  

From ttmrichter at gmail.com  Mon Oct  4 04:23:37 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Mon, 4 Oct 2010 10:23:37 +0800
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
Message-ID: <AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>

What does an ARRAY [0..-1] OF <anything> actually look like?

On 3 October 2010 20:51, Jay K <jay.krell at cornell.edu> wrote:

>
> ../src/Common/X.i3: In function 'X_I3':
> ../src/Common/X.i3:4845:0: internal compiler error: in
> m3cg_declare_subrange, at m3cg/parse.c:3567
>
>
>   gcc_assert (min <= max);
>
>   XClientMessageEvent = RECORD
>      type: int;
>      serial: unsigned_long;    (* # of last request processed by server *)
>      send_event: Bool;         (* true if this came from a SendEvent
> request *)
>      display: DisplayStar;     (* Display the event was read from *)
>      window: Window;
>      message_type: Atom;
>      format: int;
>      alignment: ARRAY [0..-1] OF long;
>      data: ARRAY [0..MAX (20 * BYTESIZE (char),
>                           MAX (10 * BYTESIZE (short),
>                                5 * BYTESIZE (long))) - 1] OF char; END;
>
>
>      alignment: ARRAY [0..-1] OF long;
>
>
> typedef struct {
>     int type;
>     unsigned long serial;    /* # of last request processed by server */
>     Bool send_event;    /* true if this came from a SendEvent request */
>     Display *display;    /* Display the event was read from */
>     Window window;
>     Atom message_type;
>     int format;
>     union {
>         char b[20];
>         short s[10];
>         long l[5];
>         } data;
> } XClientMessageEvent;
>
>
>
> eh?
>
>
> I'll remove the assert.
> "Clearly"? the Modula-3 should just use an array of long though for the
> union?
>
>
>  - Jay
>
>




-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101004/220b0cd5/attachment-0002.html>

From hosking at cs.purdue.edu  Mon Oct  4 06:08:50 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 00:08:50 -0400
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>
Message-ID: <1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>

It's an array with no elements, since the subrange [0..-1] is empty.

On 3 Oct 2010, at 22:23, Michael Richter wrote:

> What does an ARRAY [0..-1] OF <anything> actually look like?
> 
> On 3 October 2010 20:51, Jay K <jay.krell at cornell.edu> wrote:
> 
> ../src/Common/X.i3: In function 'X_I3':
> ../src/Common/X.i3:4845:0: internal compiler error: in m3cg_declare_subrange, at m3cg/parse.c:3567
> 
> 
>   gcc_assert (min <= max);
> 
>   XClientMessageEvent = RECORD
>      type: int;
>      serial: unsigned_long;    (* # of last request processed by server *)
>      send_event: Bool;         (* true if this came from a SendEvent request *)
>      display: DisplayStar;     (* Display the event was read from *)
>      window: Window;
>      message_type: Atom;
>      format: int;
>      alignment: ARRAY [0..-1] OF long;
>      data: ARRAY [0..MAX (20 * BYTESIZE (char),
>                           MAX (10 * BYTESIZE (short),
>                                5 * BYTESIZE (long))) - 1] OF char; END;
> 
> 
>      alignment: ARRAY [0..-1] OF long;
> 
> 
> typedef struct {
>     int type;
>     unsigned long serial;    /* # of last request processed by server */
>     Bool send_event;    /* true if this came from a SendEvent request */
>     Display *display;    /* Display the event was read from */
>     Window window;
>     Atom message_type;
>     int format;
>     union {
>         char b[20];
>         short s[10];
>         long l[5];
>         } data;
> } XClientMessageEvent;
> 
> 
> 
> eh?
> 
> 
> I'll remove the assert.
> "Clearly"? the Modula-3 should just use an array of long though for the union?
> 
> 
>  - Jay
> 
>                                          
> 
> 
> 
> -- 
> "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

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

From jay.krell at cornell.edu  Mon Oct  4 12:35:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 10:35:25 +0000
Subject: [M3devel] unnecessary temporaries in m3cc/parse.c
In-Reply-To: <6074704E-AF87-43FF-AE7D-361E8A6CD47D@cs.purdue.edu>
References: <COL101-W245E086BF6735E845138E5E66B0@phx.gbl>,
	<6074704E-AF87-43FF-AE7D-361E8A6CD47D@cs.purdue.edu>
Message-ID: <COL101-W4C498D5F36D9300A3A44FE66C0@phx.gbl>


The first bunch are gone now.
The second few are more work and less interesting. Floating point -- meh.
stabilize_reference I sprinkled all around.

?? - Jay

________________________________
> Subject: Re: [M3devel] unnecessary temporaries in m3cc/parse.c
> From: hosking at cs.purdue.edu
> Date: Sun, 3 Oct 2010 17:05:40 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> Seems reasonable. The reasons may be lost in the mists of time...
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 3 Oct 2010, at 04:00, Jay K wrote:
>
>
> I fail to understand why the following need explicit temporaries:
>
> check_nil
> check_lo
> check_hi
> check_range
> check_eq
> shift
> rotate
>
> probably even:
> round
> floor
> ceiling
>
> but floating point doesn't matter so much.
>
> "stabilize_reference" can be used to avoid recomputing values.
>
> - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 12:41:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 10:41:02 +0000
Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg?
In-Reply-To: <20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
References: <COL101-W45FE53C3E422B9654C4EDFE6680@phx.gbl>, ,
	<1285845869.2729.7.camel@boromir.m3w.org>,
	<COL101-W45C41525E99EEE5C4CD20EE6690@phx.gbl>,
	<20101001123723.8yne3337qos4ksoc@mail.elegosoft.com>
Message-ID: <COL101-w65521D7AAC25DB29CD13B6E66C0@phx.gbl>


 > Olaff
 > We can easily support cross-builds from
 > all 32 bit targets to all
 > 32 bit targets and from 64 bit targets to
 > both 32 and 64 bit targets, right?
 
 Correct. 
 Still, I'm very inclined to fix it. 
 Either Target.Int or LONGINT should be used "everywhere". 
 gcc uses long long heavily internally for this purpose,
  if targeting 64bit from 32bit, though
  it also has available "double_int" and gmp.

 - Jay
 		 	   		  

From wagner at elegosoft.com  Mon Oct  4 16:45:46 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 04 Oct 2010 16:45:46 +0200
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>
Message-ID: <20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> I think I'll just solve this in the backend by making a few passes.
> Maybe something with specific passes where early passes only pay
> attention to certain opcodes, that declare types.

I'm not really happy with multiple passes within the backend just to
make gcc happy. The performance of the gcc backend is already poor
compared to an integrated backend and to what M3 should be able to
achieve. How much will it cost wrt. performance?

> The new/current "replay" stuff will maybe go away.

Hm, I must have missed that.

> The new/current keeping of the entire file in memory will stay
> unless someone has strong evidence/argument that is shouldn't.

Keeping the whole (intermediate code) file in memory should be fine,
unless we get problems for large generated files on small machines
somewhere.

How big are the intermediate files for all our own sources?
Can you write out some statistics?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Mon Oct  4 19:03:08 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 17:03:08 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>
Message-ID: <COL101-W63A85230DF18466658F59BE66C0@phx.gbl>


The passes I'm talking about I think will be fast.
True the backend is very slow but I don't think this will matter.
The earlier will passes will ignore most of the data.
The cost will only be in the extra but ignored serialization.
And even then, it might be better -- if the ordering is a certain way
and guaranteed, once it hits certain opcodes, it will know the types
are all done and start over, without walking each opcode one at a time.

I tried building m3cc on virtual machines with only 256MB and it failed.
I had to up to 384 MB. If I cal recall correctly.

Granted, we don't always build m3cc.

Remember that optimized builds would often use "unit at once"
?compilation, so the entire gcc tree would be in memory.
Now, currently, we never do that for Modula-3, because of a bug
where it throws out functions that are needed to be kept.
But for C/C++ it is not unusual (again, including compiling m3cc).
The tree representation is presumably not much different/smaller than
the m3cg representation. For actual C/C++ there might be a bigger difference,
what with comments/whitespace removed.
But from the gcc point of view, Modula-3 source is already in an encoded binary form.
Granted, the strings are duplicatd.

Still, the access pattern remains linear.
So it doesn't increase working set. Just virtual address space requiremens.

This is something I learned reeently working with large data -- linear access
patterns are what is good and keeps working set down, vs. random access.

Plus, the file gets closed which does free a little of resources, though
probably less than are being additional consumed.

?- Jay

----------------------------------------
> Date: Mon, 4 Oct 2010 16:45:46 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> Quoting Jay K :
>
> > I think I'll just solve this in the backend by making a few passes.
> > Maybe something with specific passes where early passes only pay
> > attention to certain opcodes, that declare types.
>
> I'm not really happy with multiple passes within the backend just to
> make gcc happy. The performance of the gcc backend is already poor
> compared to an integrated backend and to what M3 should be able to
> achieve. How much will it cost wrt. performance?
>
> > The new/current "replay" stuff will maybe go away.
>
> Hm, I must have missed that.
>
> > The new/current keeping of the entire file in memory will stay
> > unless someone has strong evidence/argument that is shouldn't.
>
> Keeping the whole (intermediate code) file in memory should be fine,
> unless we get problems for large generated files on small machines
> somewhere.
>
> How big are the intermediate files for all our own sources?
> Can you write out some statistics?
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 19:16:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 17:16:05 +0000
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
Message-ID: <COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>


It worries me somewhat that we allow zero-sized types.
Including TYPE Foo = RECORD END;
It is reassuring to me that C and C++ doesn't have these.
I don't want to think about what they mean.
Do they make sense to others?

C requires a field. C++ adds a dummy one internally, that it can/must try
to optimize away when inheritance is involved but still.


C++ is interested in the property of pointers not being equal, like:

TYPE T1 = RECORD END;
TYPE T2 = RECORD a,b:T1 END;

VAR a:T1;
ADR(a.b) # ADR(a.a.);

But in Modula-3 they would have the same address.
What does it mean to take the address of something that doesn't exist?
Perhaps it isn't allowed?

As well this kind of thing worries me because Modula-3 truly is
mostly trivially isomorphic with C, which means it is easy to imagine
the gcc backend can handle it. This is an exception.
Sure, there probably is a transform to C, it just isn't obvious to me.
(Granted as well, the gcc backend handles Ada, and Pascal,
so it isn't so limited. Ada at least superficially looks like
Modula-3, I was surprised to see.)

?- Jay

________________________________
> Subject: Re: [M3devel] subranges 0..-1?
> From: hosking at cs.purdue.edu
> Date: Mon, 4 Oct 2010 00:08:50 -0400
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> To: ttmrichter at gmail.com
>
> It's an array with no elements, since the subrange [0..-1] is empty.
>
> On 3 Oct 2010, at 22:23, Michael Richter wrote:
>
> What does an ARRAY [0..-1] OF actually look like?
>
> On 3 October 2010 20:51, Jay K
> > wrote:
>
> ../src/Common/X.i3: In function 'X_I3':
> ../src/Common/X.i3:4845:0: internal compiler error: in
> m3cg_declare_subrange, at m3cg/parse.c:3567
>
>
> gcc_assert (min <= max);
>
> XClientMessageEvent = RECORD
> type: int;
> serial: unsigned_long; (* # of last request processed by server *)
> send_event: Bool; (* true if this came from a SendEvent
> request *)
> display: DisplayStar; (* Display the event was read from *)
> window: Window;
> message_type: Atom;
> format: int;
> alignment: ARRAY [0..-1] OF long;
> data: ARRAY [0..MAX (20 * BYTESIZE (char),
> MAX (10 * BYTESIZE (short),
> 5 * BYTESIZE (long))) - 1] OF char; END;
>
>
> alignment: ARRAY [0..-1] OF long;
>
>
> typedef struct {
> int type;
> unsigned long serial; /* # of last request processed by server */
> Bool send_event; /* true if this came from a SendEvent request */
> Display *display; /* Display the event was read from */
> Window window;
> Atom message_type;
> int format;
> union {
> char b[20];
> short s[10];
> long l[5];
> } data;
> } XClientMessageEvent;
>
>
>
> eh?
>
>
> I'll remove the assert.
> "Clearly"? the Modula-3 should just use an array of long though for the
> union?
>
>
> - Jay
>
>
>
>
>
> --
> "Perhaps people don't believe this, but throughout all of the
> discussions of entering China our focus has really been what's best for
> the Chinese people. It's not been about our revenue or profit or
> whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 19:23:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 17:23:16 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W63A85230DF18466658F59BE66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>
Message-ID: <COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>


ps: gcc has a very large number of passes over its trees, at least when optimizing.
Like tens or 100+.
The Modula-3 frontend also makes a few passes over everything, just a few.
I don't know where the cost is, but I don't expect to add much. We'll see.
I can try to limit it to not even walk the non-type data.
I should see if the frontend reliably front-loads the type data. It seems to.
We could also put in an end-types opcode to? make it easier to notice.
I think we could also address it in the frontend, by introducing
a type forward declaration call.


> > How big are the intermediate files for all our own sources?


A few months ago I took a quick survey.
This is when I grew the buffer fromwhateve it was to 64K.
I couldn't justify larger because so many would fit in 64K.

I lied somewhat about working set.
If you use a small buffer and iterate in place, your working
set can only grow by the size of the buffer.
If you read the entire thing into memory and walk it linearly,
well, the operating system doesn't necessarily know you won't
walk backwards so it'll let your working set grow, only to throw
out the memory later as needed. This is my rough understanding
based on OS principles. As well, using more address space
has a little extra cost, vs. looping over a small buffer multiple times.

We might might might be able to make some optimizations though,
such as having strings be direct pointers into the buffer instead
of copying them out. There is the matter of the terminal nuls though.
And checking that they fit in the buffer.

> > Can you write out some statistics?


Yeah..
I routinely use cm3 -keep, then just -l target/*c


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com; m3devel at elegosoft.com
> Date: Mon, 4 Oct 2010 17:03:08 +0000
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
>
> The passes I'm talking about I think will be fast.
> True the backend is very slow but I don't think this will matter.
> The earlier will passes will ignore most of the data.
> The cost will only be in the extra but ignored serialization.
> And even then, it might be better -- if the ordering is a certain way
> and guaranteed, once it hits certain opcodes, it will know the types
> are all done and start over, without walking each opcode one at a time.
>
> I tried building m3cc on virtual machines with only 256MB and it failed.
> I had to up to 384 MB. If I cal recall correctly.
>
> Granted, we don't always build m3cc.
>
> Remember that optimized builds would often use "unit at once"
>  compilation, so the entire gcc tree would be in memory.
> Now, currently, we never do that for Modula-3, because of a bug
> where it throws out functions that are needed to be kept.
> But for C/C++ it is not unusual (again, including compiling m3cc).
> The tree representation is presumably not much different/smaller than
> the m3cg representation. For actual C/C++ there might be a bigger difference,
> what with comments/whitespace removed.
> But from the gcc point of view, Modula-3 source is already in an encoded binary form.
> Granted, the strings are duplicatd.
>
> Still, the access pattern remains linear.
> So it doesn't increase working set. Just virtual address space requiremens.
>
> This is something I learned reeently working with large data -- linear access
> patterns are what is good and keeps working set down, vs. random access.
>
> Plus, the file gets closed which does free a little of resources, though
> probably less than are being additional consumed.
>
>  - Jay
>
> ----------------------------------------
> > Date: Mon, 4 Oct 2010 16:45:46 +0200
> > From: wagner at elegosoft.com
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] backend interface vs. types vs. forward references?
> >
> > Quoting Jay K :
> >
> > > I think I'll just solve this in the backend by making a few passes.
> > > Maybe something with specific passes where early passes only pay
> > > attention to certain opcodes, that declare types.
> >
> > I'm not really happy with multiple passes within the backend just to
> > make gcc happy. The performance of the gcc backend is already poor
> > compared to an integrated backend and to what M3 should be able to
> > achieve. How much will it cost wrt. performance?
> >
> > > The new/current "replay" stuff will maybe go away.
> >
> > Hm, I must have missed that.
> >
> > > The new/current keeping of the entire file in memory will stay
> > > unless someone has strong evidence/argument that is shouldn't.
> >
> > Keeping the whole (intermediate code) file in memory should be fine,
> > unless we get problems for large generated files on small machines
> > somewhere.
> >
> > How big are the intermediate files for all our own sources?
> > Can you write out some statistics?
> >
> > Olaf
> > --
> > Olaf Wagner -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >
>
 		 	   		  

From hosking at cs.purdue.edu  Mon Oct  4 19:47:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 13:47:12 -0400
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>
Message-ID: <FC69BD7C-9D55-4642-9F44-0BB86D00DEA1@cs.purdue.edu>

Sure, they make sense.  Just like arrays with no elements.  I don't understand your fearfulness, unless it is just C poisoning your thinking.

On 4 Oct 2010, at 13:16, Jay K wrote:

> 
> It worries me somewhat that we allow zero-sized types.
> Including TYPE Foo = RECORD END;
> It is reassuring to me that C and C++ doesn't have these.
> I don't want to think about what they mean.
> Do they make sense to others?
> 
> C requires a field. C++ adds a dummy one internally, that it can/must try
> to optimize away when inheritance is involved but still.
> 
> 
> C++ is interested in the property of pointers not being equal, like:
> 
> TYPE T1 = RECORD END;
> TYPE T2 = RECORD a,b:T1 END;
> 
> VAR a:T1;
> ADR(a.b) # ADR(a.a.);
> 
> But in Modula-3 they would have the same address.
> What does it mean to take the address of something that doesn't exist?
> Perhaps it isn't allowed?
> 
> As well this kind of thing worries me because Modula-3 truly is
> mostly trivially isomorphic with C, which means it is easy to imagine
> the gcc backend can handle it. This is an exception.
> Sure, there probably is a transform to C, it just isn't obvious to me.
> (Granted as well, the gcc backend handles Ada, and Pascal,
> so it isn't so limited. Ada at least superficially looks like
> Modula-3, I was surprised to see.)
> 
>  - Jay
> 
> ________________________________
>> Subject: Re: [M3devel] subranges 0..-1?
>> From: hosking at cs.purdue.edu
>> Date: Mon, 4 Oct 2010 00:08:50 -0400
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: ttmrichter at gmail.com
>> 
>> It's an array with no elements, since the subrange [0..-1] is empty.
>> 
>> On 3 Oct 2010, at 22:23, Michael Richter wrote:
>> 
>> What does an ARRAY [0..-1] OF actually look like?
>> 
>> On 3 October 2010 20:51, Jay K
>>> wrote:
>> 
>> ../src/Common/X.i3: In function 'X_I3':
>> ../src/Common/X.i3:4845:0: internal compiler error: in
>> m3cg_declare_subrange, at m3cg/parse.c:3567
>> 
>> 
>> gcc_assert (min <= max);
>> 
>> XClientMessageEvent = RECORD
>> type: int;
>> serial: unsigned_long; (* # of last request processed by server *)
>> send_event: Bool; (* true if this came from a SendEvent
>> request *)
>> display: DisplayStar; (* Display the event was read from *)
>> window: Window;
>> message_type: Atom;
>> format: int;
>> alignment: ARRAY [0..-1] OF long;
>> data: ARRAY [0..MAX (20 * BYTESIZE (char),
>> MAX (10 * BYTESIZE (short),
>> 5 * BYTESIZE (long))) - 1] OF char; END;
>> 
>> 
>> alignment: ARRAY [0..-1] OF long;
>> 
>> 
>> typedef struct {
>> int type;
>> unsigned long serial; /* # of last request processed by server */
>> Bool send_event; /* true if this came from a SendEvent request */
>> Display *display; /* Display the event was read from */
>> Window window;
>> Atom message_type;
>> int format;
>> union {
>> char b[20];
>> short s[10];
>> long l[5];
>> } data;
>> } XClientMessageEvent;
>> 
>> 
>> 
>> eh?
>> 
>> 
>> I'll remove the assert.
>> "Clearly"? the Modula-3 should just use an array of long though for the
>> union?
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> 
>> --
>> "Perhaps people don't believe this, but throughout all of the
>> discussions of entering China our focus has really been what's best for
>> the Chinese people. It's not been about our revenue or profit or
>> whatnot."
>> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>> 
> 		 	   		  



From hosking at cs.purdue.edu  Mon Oct  4 19:49:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 13:49:51 -0400
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
Message-ID: <13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>

I see no problem walking the IR trees again to fill in the type information.  Can't you make it part of the lowering pass to GIMPLE?


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 4 Oct 2010, at 13:23, Jay K wrote:

> 
> ps: gcc has a very large number of passes over its trees, at least when optimizing.
> Like tens or 100+.
> The Modula-3 frontend also makes a few passes over everything, just a few.
> I don't know where the cost is, but I don't expect to add much. We'll see.
> I can try to limit it to not even walk the non-type data.
> I should see if the frontend reliably front-loads the type data. It seems to.
> We could also put in an end-types opcode to  make it easier to notice.
> I think we could also address it in the frontend, by introducing
> a type forward declaration call.
> 
> 
>>> How big are the intermediate files for all our own sources?
> 
> 
> A few months ago I took a quick survey.
> This is when I grew the buffer fromwhateve it was to 64K.
> I couldn't justify larger because so many would fit in 64K.
> 
> I lied somewhat about working set.
> If you use a small buffer and iterate in place, your working
> set can only grow by the size of the buffer.
> If you read the entire thing into memory and walk it linearly,
> well, the operating system doesn't necessarily know you won't
> walk backwards so it'll let your working set grow, only to throw
> out the memory later as needed. This is my rough understanding
> based on OS principles. As well, using more address space
> has a little extra cost, vs. looping over a small buffer multiple times.
> 
> We might might might be able to make some optimizations though,
> such as having strings be direct pointers into the buffer instead
> of copying them out. There is the matter of the terminal nuls though.
> And checking that they fit in the buffer.
> 
>>> Can you write out some statistics?
> 
> 
> Yeah..
> I routinely use cm3 -keep, then just -l target/*c
> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: wagner at elegosoft.com; m3devel at elegosoft.com
>> Date: Mon, 4 Oct 2010 17:03:08 +0000
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> 
>> The passes I'm talking about I think will be fast.
>> True the backend is very slow but I don't think this will matter.
>> The earlier will passes will ignore most of the data.
>> The cost will only be in the extra but ignored serialization.
>> And even then, it might be better -- if the ordering is a certain way
>> and guaranteed, once it hits certain opcodes, it will know the types
>> are all done and start over, without walking each opcode one at a time.
>> 
>> I tried building m3cc on virtual machines with only 256MB and it failed.
>> I had to up to 384 MB. If I cal recall correctly.
>> 
>> Granted, we don't always build m3cc.
>> 
>> Remember that optimized builds would often use "unit at once"
>> compilation, so the entire gcc tree would be in memory.
>> Now, currently, we never do that for Modula-3, because of a bug
>> where it throws out functions that are needed to be kept.
>> But for C/C++ it is not unusual (again, including compiling m3cc).
>> The tree representation is presumably not much different/smaller than
>> the m3cg representation. For actual C/C++ there might be a bigger difference,
>> what with comments/whitespace removed.
>> But from the gcc point of view, Modula-3 source is already in an encoded binary form.
>> Granted, the strings are duplicatd.
>> 
>> Still, the access pattern remains linear.
>> So it doesn't increase working set. Just virtual address space requiremens.
>> 
>> This is something I learned reeently working with large data -- linear access
>> patterns are what is good and keeps working set down, vs. random access.
>> 
>> Plus, the file gets closed which does free a little of resources, though
>> probably less than are being additional consumed.
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> Date: Mon, 4 Oct 2010 16:45:46 +0200
>>> From: wagner at elegosoft.com
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>>> 
>>> Quoting Jay K :
>>> 
>>>> I think I'll just solve this in the backend by making a few passes.
>>>> Maybe something with specific passes where early passes only pay
>>>> attention to certain opcodes, that declare types.
>>> 
>>> I'm not really happy with multiple passes within the backend just to
>>> make gcc happy. The performance of the gcc backend is already poor
>>> compared to an integrated backend and to what M3 should be able to
>>> achieve. How much will it cost wrt. performance?
>>> 
>>>> The new/current "replay" stuff will maybe go away.
>>> 
>>> Hm, I must have missed that.
>>> 
>>>> The new/current keeping of the entire file in memory will stay
>>>> unless someone has strong evidence/argument that is shouldn't.
>>> 
>>> Keeping the whole (intermediate code) file in memory should be fine,
>>> unless we get problems for large generated files on small machines
>>> somewhere.
>>> 
>>> How big are the intermediate files for all our own sources?
>>> Can you write out some statistics?
>>> 
>>> Olaf
>>> --
>>> Olaf Wagner -- elego Software Solutions GmbH
>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>> 
>> 
> 		 	   		  

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

From jay.krell at cornell.edu  Mon Oct  4 20:05:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 18:05:57 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>,
	,,<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>,
	, , <20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>, ,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>,
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>,
	<13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>
Message-ID: <COL101-W23F3AFD8BE5D29A26C6E43E66C0@phx.gbl>


I think I understand and I think so.
Rather than lowing to gimple though, it could just be before all that, right?
I mean, walking the gcc trees and converting from "pre-gimple" to "pre-gimple", right?
i.e. not lowering, just transform within same "space"?

What I was talking about though was walking the m3cg opcode IR.
At least the initial type declaration part.

A new m3cg call to just forward declare types might be good too, instead.

?- Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Mon, 4 Oct 2010 13:49:51 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> I see no problem walking the IR trees again to fill in the type
> information. Can't you make it part of the lowering pass to GIMPLE?
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 4 Oct 2010, at 13:23, Jay K wrote:
>
>
> ps: gcc has a very large number of passes over its trees, at least when
> optimizing.
> Like tens or 100+.
> The Modula-3 frontend also makes a few passes over everything, just a few.
> I don't know where the cost is, but I don't expect to add much. We'll see.
> I can try to limit it to not even walk the non-type data.
> I should see if the frontend reliably front-loads the type data. It seems to.
> We could also put in an end-types opcode to make it easier to notice.
> I think we could also address it in the frontend, by introducing
> a type forward declaration call.
>
>
> How big are the intermediate files for all our own sources?
>
>
> A few months ago I took a quick survey.
> This is when I grew the buffer fromwhateve it was to 64K.
> I couldn't justify larger because so many would fit in 64K.
>
> I lied somewhat about working set.
> If you use a small buffer and iterate in place, your working
> set can only grow by the size of the buffer.
> If you read the entire thing into memory and walk it linearly,
> well, the operating system doesn't necessarily know you won't
> walk backwards so it'll let your working set grow, only to throw
> out the memory later as needed. This is my rough understanding
> based on OS principles. As well, using more address space
> has a little extra cost, vs. looping over a small buffer multiple times.
>
> We might might might be able to make some optimizations though,
> such as having strings be direct pointers into the buffer instead
> of copying them out. There is the matter of the terminal nuls though.
> And checking that they fit in the buffer.
>
> Can you write out some statistics?
>
>
> Yeah..
> I routinely use cm3 -keep, then just -l target/*c
>
>
> - Jay
>
> ----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com;
> m3devel at elegosoft.com
> Date: Mon, 4 Oct 2010 17:03:08 +0000
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
>
> The passes I'm talking about I think will be fast.
> True the backend is very slow but I don't think this will matter.
> The earlier will passes will ignore most of the data.
> The cost will only be in the extra but ignored serialization.
> And even then, it might be better -- if the ordering is a certain way
> and guaranteed, once it hits certain opcodes, it will know the types
> are all done and start over, without walking each opcode one at a time.
>
> I tried building m3cc on virtual machines with only 256MB and it failed.
> I had to up to 384 MB. If I cal recall correctly.
>
> Granted, we don't always build m3cc.
>
> Remember that optimized builds would often use "unit at once"
> compilation, so the entire gcc tree would be in memory.
> Now, currently, we never do that for Modula-3, because of a bug
> where it throws out functions that are needed to be kept.
> But for C/C++ it is not unusual (again, including compiling m3cc).
> The tree representation is presumably not much different/smaller than
> the m3cg representation. For actual C/C++ there might be a bigger difference,
> what with comments/whitespace removed.
> But from the gcc point of view, Modula-3 source is already in an
> encoded binary form.
> Granted, the strings are duplicatd.
>
> Still, the access pattern remains linear.
> So it doesn't increase working set. Just virtual address space requiremens.
>
> This is something I learned reeently working with large data -- linear access
> patterns are what is good and keeps working set down, vs. random access.
>
> Plus, the file gets closed which does free a little of resources, though
> probably less than are being additional consumed.
>
> - Jay
>
> ----------------------------------------
> Date: Mon, 4 Oct 2010 16:45:46 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> Quoting Jay K :
>
> I think I'll just solve this in the backend by making a few passes.
> Maybe something with specific passes where early passes only pay
> attention to certain opcodes, that declare types.
>
> I'm not really happy with multiple passes within the backend just to
> make gcc happy. The performance of the gcc backend is already poor
> compared to an integrated backend and to what M3 should be able to
> achieve. How much will it cost wrt. performance?
>
> The new/current "replay" stuff will maybe go away.
>
> Hm, I must have missed that.
>
> The new/current keeping of the entire file in memory will stay
> unless someone has strong evidence/argument that is shouldn't.
>
> Keeping the whole (intermediate code) file in memory should be fine,
> unless we get problems for large generated files on small machines
> somewhere.
>
> How big are the intermediate files for all our own sources?
> Can you write out some statistics?
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>
>
>
 		 	   		  

From mika at async.async.caltech.edu  Mon Oct  4 20:12:08 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 04 Oct 2010 11:12:08 -0700
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W481C04C97A03C69858A03BE66C0@phx.gbl> 
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>
Message-ID: <20101004181208.154661A208C@async.async.caltech.edu>

Jay K writes:
>
>It worries me somewhat that we allow zero-sized types.
>Including TYPE Foo =3D RECORD END=3B
>It is reassuring to me that C and C++ doesn't have these.
>I don't want to think about what they mean.
>Do they make sense to others?

Yes, they make a lot of sense.  Not having them means special-casing
any program that generates code.  Obviously a correct program that generates
code including a zero-sized array will never generate an expression
that indexes such an array...

>
>C requires a field. C++ adds a dummy one internally=2C that it can/must try
>to optimize away when inheritance is involved but still.
>
>
>C++ is interested in the property of pointers not being equal=2C like:
>
>TYPE T1 =3D RECORD END=3B
>TYPE T2 =3D RECORD a=2Cb:T1 END=3B
>
>VAR a:T1=3B
>ADR(a.b) # ADR(a.a.)=3B
>
>But in Modula-3 they would have the same address.
>What does it mean to take the address of something that doesn't exist?
>Perhaps it isn't allowed?

This is UNSAFE code, so it means whatever the implementation makes
it mean, including (as far as I'm concerned) a compiler crash, if
that is the easiest thing you can make it mean.  I really wouldn't
worry about the UNSAFE parts of Modula-3 that much...  expected to be
implementation-dependent.  Although I admit it would be better to have
it do something meaningless in this case.  Since T1 is an empty type
there's not much you can do with the address anyhow.

    Mika


From jay.krell at cornell.edu  Mon Oct  4 20:30:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 18:30:31 +0000
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <20101004181208.154661A208C@async.async.caltech.edu>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>,
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>, ,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>,
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>,
	<20101004181208.154661A208C@async.async.caltech.edu>
Message-ID: <COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>


So, I'm not supposed to worry about unsafe stuff..including if the backend and debugging information can? handle it? No.
Unsafe code matters, a lot.

?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> Date: Mon, 4 Oct 2010 11:12:08 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] subranges 0..-1?
>
> Jay K writes:
> >
> >It worries me somewhat that we allow zero-sized types.
> >Including TYPE Foo =3D RECORD END=3B
> >It is reassuring to me that C and C++ doesn't have these.
> >I don't want to think about what they mean.
> >Do they make sense to others?
>
> Yes, they make a lot of sense. Not having them means special-casing
> any program that generates code. Obviously a correct program that generates
> code including a zero-sized array will never generate an expression
> that indexes such an array...
>
> >
> >C requires a field. C++ adds a dummy one internally=2C that it can/must try
> >to optimize away when inheritance is involved but still.
> >
> >
> >C++ is interested in the property of pointers not being equal=2C like:
> >
> >TYPE T1 =3D RECORD END=3B
> >TYPE T2 =3D RECORD a=2Cb:T1 END=3B
> >
> >VAR a:T1=3B
> >ADR(a.b) # ADR(a.a.)=3B
> >
> >But in Modula-3 they would have the same address.
> >What does it mean to take the address of something that doesn't exist?
> >Perhaps it isn't allowed?
>
> This is UNSAFE code, so it means whatever the implementation makes
> it mean, including (as far as I'm concerned) a compiler crash, if
> that is the easiest thing you can make it mean. I really wouldn't
> worry about the UNSAFE parts of Modula-3 that much... expected to be
> implementation-dependent. Although I admit it would be better to have
> it do something meaningless in this case. Since T1 is an empty type
> there's not much you can do with the address anyhow.
>
> Mika
 		 	   		  

From jay.krell at cornell.edu  Mon Oct  4 21:02:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 4 Oct 2010 19:02:02 +0000
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>,
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>
Message-ID: <COL101-W3436C5D1E0DEEAD71F2C9FE66C0@phx.gbl>


> ps: gcc has a very large number of passes over its trees, at least when optimizing.

according to the documentation, there
are around 100 SSA form optimization passes and 70 RTL optimization passes
-O2 and -O3 are noticably slower than -O0.
? (and -enable-checking=all is much slower again, and we do still have problems there..)

Bing for "gcc internal passes" and you should find it.

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon Oct  4 22:39:57 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 16:39:57 -0400
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>,
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>, ,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>,
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>,
	<20101004181208.154661A208C@async.async.caltech.edu>
	<COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>
Message-ID: <38B55395-49EA-4B95-BB16-C2A08C279BA5@cs.purdue.edu>

How does the backend handle empty Pascal records?

On 4 Oct 2010, at 14:30, Jay K wrote:

> 
> So, I'm not supposed to worry about unsafe stuff..including if the backend and debugging information can  handle it? No.
> Unsafe code matters, a lot.
> 
>  - Jay
> 
> ----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Mon, 4 Oct 2010 11:12:08 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] subranges 0..-1?
>> 
>> Jay K writes:
>>> 
>>> It worries me somewhat that we allow zero-sized types.
>>> Including TYPE Foo =3D RECORD END=3B
>>> It is reassuring to me that C and C++ doesn't have these.
>>> I don't want to think about what they mean.
>>> Do they make sense to others?
>> 
>> Yes, they make a lot of sense. Not having them means special-casing
>> any program that generates code. Obviously a correct program that generates
>> code including a zero-sized array will never generate an expression
>> that indexes such an array...
>> 
>>> 
>>> C requires a field. C++ adds a dummy one internally=2C that it can/must try
>>> to optimize away when inheritance is involved but still.
>>> 
>>> 
>>> C++ is interested in the property of pointers not being equal=2C like:
>>> 
>>> TYPE T1 =3D RECORD END=3B
>>> TYPE T2 =3D RECORD a=2Cb:T1 END=3B
>>> 
>>> VAR a:T1=3B
>>> ADR(a.b) # ADR(a.a.)=3B
>>> 
>>> But in Modula-3 they would have the same address.
>>> What does it mean to take the address of something that doesn't exist?
>>> Perhaps it isn't allowed?
>> 
>> This is UNSAFE code, so it means whatever the implementation makes
>> it mean, including (as far as I'm concerned) a compiler crash, if
>> that is the easiest thing you can make it mean. I really wouldn't
>> worry about the UNSAFE parts of Modula-3 that much... expected to be
>> implementation-dependent. Although I admit it would be better to have
>> it do something meaningless in this case. Since T1 is an empty type
>> there's not much you can do with the address anyhow.
>> 
>> Mika
> 		 	   		  



From hosking at cs.purdue.edu  Mon Oct  4 22:41:35 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 4 Oct 2010 16:41:35 -0400
Subject: [M3devel] backend interface vs. types vs. forward references?
In-Reply-To: <COL101-W23F3AFD8BE5D29A26C6E43E66C0@phx.gbl>
References: <COL101-W38604BBA82FD44F30FD784E66B0@phx.gbl>, , ,
	<COL101-W17704F75C8B29EB27134F0E66B0@phx.gbl>, , ,
	<20101004164546.diyqk0gz7wowcos0@mail.elegosoft.com>, ,
	<COL101-W63A85230DF18466658F59BE66C0@phx.gbl>,
	<COL101-W31A0C3B167D46C72149C27E66C0@phx.gbl>,
	<13A8AEF2-FA02-46F2-839D-4606869457D9@cs.purdue.edu>
	<COL101-W23F3AFD8BE5D29A26C6E43E66C0@phx.gbl>
Message-ID: <0B6701D7-46BE-458D-8B25-34D2ABD35D77@cs.purdue.edu>

I would avoid a new m3cg.  Just walk the tree as you say.

On 4 Oct 2010, at 14:05, Jay K wrote:

> 
> I think I understand and I think so.
> Rather than lowing to gimple though, it could just be before all that, right?
> I mean, walking the gcc trees and converting from "pre-gimple" to "pre-gimple", right?
> i.e. not lowering, just transform within same "space"?
> 
> What I was talking about though was walking the m3cg opcode IR.
> At least the initial type declaration part.
> 
> A new m3cg call to just forward declare types might be good too, instead.
> 
>  - Jay
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Mon, 4 Oct 2010 13:49:51 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> I see no problem walking the IR trees again to fill in the type
>> information. Can't you make it part of the lowering pass to GIMPLE?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> On 4 Oct 2010, at 13:23, Jay K wrote:
>> 
>> 
>> ps: gcc has a very large number of passes over its trees, at least when
>> optimizing.
>> Like tens or 100+.
>> The Modula-3 frontend also makes a few passes over everything, just a few.
>> I don't know where the cost is, but I don't expect to add much. We'll see.
>> I can try to limit it to not even walk the non-type data.
>> I should see if the frontend reliably front-loads the type data. It seems to.
>> We could also put in an end-types opcode to make it easier to notice.
>> I think we could also address it in the frontend, by introducing
>> a type forward declaration call.
>> 
>> 
>> How big are the intermediate files for all our own sources?
>> 
>> 
>> A few months ago I took a quick survey.
>> This is when I grew the buffer fromwhateve it was to 64K.
>> I couldn't justify larger because so many would fit in 64K.
>> 
>> I lied somewhat about working set.
>> If you use a small buffer and iterate in place, your working
>> set can only grow by the size of the buffer.
>> If you read the entire thing into memory and walk it linearly,
>> well, the operating system doesn't necessarily know you won't
>> walk backwards so it'll let your working set grow, only to throw
>> out the memory later as needed. This is my rough understanding
>> based on OS principles. As well, using more address space
>> has a little extra cost, vs. looping over a small buffer multiple times.
>> 
>> We might might might be able to make some optimizations though,
>> such as having strings be direct pointers into the buffer instead
>> of copying them out. There is the matter of the terminal nuls though.
>> And checking that they fit in the buffer.
>> 
>> Can you write out some statistics?
>> 
>> 
>> Yeah..
>> I routinely use cm3 -keep, then just -l target/*c
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: wagner at elegosoft.com;
>> m3devel at elegosoft.com
>> Date: Mon, 4 Oct 2010 17:03:08 +0000
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> 
>> The passes I'm talking about I think will be fast.
>> True the backend is very slow but I don't think this will matter.
>> The earlier will passes will ignore most of the data.
>> The cost will only be in the extra but ignored serialization.
>> And even then, it might be better -- if the ordering is a certain way
>> and guaranteed, once it hits certain opcodes, it will know the types
>> are all done and start over, without walking each opcode one at a time.
>> 
>> I tried building m3cc on virtual machines with only 256MB and it failed.
>> I had to up to 384 MB. If I cal recall correctly.
>> 
>> Granted, we don't always build m3cc.
>> 
>> Remember that optimized builds would often use "unit at once"
>> compilation, so the entire gcc tree would be in memory.
>> Now, currently, we never do that for Modula-3, because of a bug
>> where it throws out functions that are needed to be kept.
>> But for C/C++ it is not unusual (again, including compiling m3cc).
>> The tree representation is presumably not much different/smaller than
>> the m3cg representation. For actual C/C++ there might be a bigger difference,
>> what with comments/whitespace removed.
>> But from the gcc point of view, Modula-3 source is already in an
>> encoded binary form.
>> Granted, the strings are duplicatd.
>> 
>> Still, the access pattern remains linear.
>> So it doesn't increase working set. Just virtual address space requiremens.
>> 
>> This is something I learned reeently working with large data -- linear access
>> patterns are what is good and keeps working set down, vs. random access.
>> 
>> Plus, the file gets closed which does free a little of resources, though
>> probably less than are being additional consumed.
>> 
>> - Jay
>> 
>> ----------------------------------------
>> Date: Mon, 4 Oct 2010 16:45:46 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>> 
>> Quoting Jay K :
>> 
>> I think I'll just solve this in the backend by making a few passes.
>> Maybe something with specific passes where early passes only pay
>> attention to certain opcodes, that declare types.
>> 
>> I'm not really happy with multiple passes within the backend just to
>> make gcc happy. The performance of the gcc backend is already poor
>> compared to an integrated backend and to what M3 should be able to
>> achieve. How much will it cost wrt. performance?
>> 
>> The new/current "replay" stuff will maybe go away.
>> 
>> Hm, I must have missed that.
>> 
>> The new/current keeping of the entire file in memory will stay
>> unless someone has strong evidence/argument that is shouldn't.
>> 
>> Keeping the whole (intermediate code) file in memory should be fine,
>> unless we get problems for large generated files on small machines
>> somewhere.
>> 
>> How big are the intermediate files for all our own sources?
>> Can you write out some statistics?
>> 
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> 
>> 
>> 
>> 
> 		 	   		  



From mika at async.async.caltech.edu  Mon Oct  4 23:16:27 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Mon, 04 Oct 2010 14:16:27 -0700
Subject: [M3devel] subranges 0..-1?
In-Reply-To: <COL101-W169957CE63F370DBAF099FE66C0@phx.gbl> 
References: <COL101-W341B180949BD08817E0FE5E66B0@phx.gbl>,
	<AANLkTikH86v1m_JFzBQCfqitj7BjoMBGRexcJcwMRCDp@mail.gmail.com>, ,
	<1C8D8520-B291-4910-B149-39B4E1FEE413@cs.purdue.edu>,
	<COL101-W481C04C97A03C69858A03BE66C0@phx.gbl>,
	<20101004181208.154661A208C@async.async.caltech.edu>
	<COL101-W169957CE63F370DBAF099FE66C0@phx.gbl>
Message-ID: <20101004211627.935681A208C@async.async.caltech.edu>

Of course unsafe code matters.

But does the particular example of unsafe code (ADR of a zero-sized
object) matter?  No, because:

1. For human-written code we use your argument.  "Don't do that"

2. Don't generate UNSAFE code by machine.  Or if you must be as careful
   as implied by 1.

     Mika

Jay K writes:
>
>So=2C I'm not supposed to worry about unsafe stuff..including if the backen=
>d and debugging information can=A0 handle it? No.
>Unsafe code matters=2C a lot.
>
>=A0- Jay
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Mon=2C 4 Oct 2010 11:12:08 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] subranges 0..-1?
>>
>> Jay K writes:
>> >
>> >It worries me somewhat that we allow zero-sized types.
>> >Including TYPE Foo =3D3D RECORD END=3D3B
>> >It is reassuring to me that C and C++ doesn't have these.
>> >I don't want to think about what they mean.
>> >Do they make sense to others?
>>
>> Yes=2C they make a lot of sense. Not having them means special-casing
>> any program that generates code. Obviously a correct program that generat=
>es
>> code including a zero-sized array will never generate an expression
>> that indexes such an array...
>>
>> >
>> >C requires a field. C++ adds a dummy one internally=3D2C that it can/mus=
>t try
>> >to optimize away when inheritance is involved but still.
>> >
>> >
>> >C++ is interested in the property of pointers not being equal=3D2C like:
>> >
>> >TYPE T1 =3D3D RECORD END=3D3B
>> >TYPE T2 =3D3D RECORD a=3D2Cb:T1 END=3D3B
>> >
>> >VAR a:T1=3D3B
>> >ADR(a.b) # ADR(a.a.)=3D3B
>> >
>> >But in Modula-3 they would have the same address.
>> >What does it mean to take the address of something that doesn't exist?
>> >Perhaps it isn't allowed?
>>
>> This is UNSAFE code=2C so it means whatever the implementation makes
>> it mean=2C including (as far as I'm concerned) a compiler crash=2C if
>> that is the easiest thing you can make it mean. I really wouldn't
>> worry about the UNSAFE parts of Modula-3 that much... expected to be
>> implementation-dependent. Although I admit it would be better to have
>> it do something meaningless in this case. Since T1 is an empty type
>> there's not much you can do with the address anyhow.
>>
>> Mika
> 		 	   		  =


From jay.krell at cornell.edu  Tue Oct  5 11:00:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 09:00:40 +0000
Subject: [M3devel] hardware clearance?
Message-ID: <COL101-W32FCFBBE44FBF546E07C71E66D0@phx.gbl>


Hey folks.
I have an impending possible need to drastically rapidly cleanup my place.
One of the biggest steps I can take is getting rid of hardware.


Anyone interested?
For free?


It is a quite a mix.? All from eBay over past 2 or so years.
Much has been seen to work, a little has been seen not work, some
has never been tried. Many have not been powered on for months/years.
All have at least some memory/hard drive, some have optical drive,
?or some I'd use external SCSI CD-ROM drive.


SPARC64, PPC64 IA64, PPC, Alpha, MIPS. Stuff capable
of running AIX, Irix, HP-UX, AMD64, VMS, Tru64, Linux,
OpenBSD, FreeBSD, NetBSD, Solaris.

Laptops I can keep.


SPARC64:
? 3x: have run Linux, OpenBSD, Solaris a while
? includes two Hudson nodes (Linux, Solaris, not OpenBSD)
? could also surely run NetBSD, FreeBSD
? at least 4 machines, not all of which have been used 
? both "workstation" and 1U form factors 
? 
? 
MIPS/SGI:
?3 x O2 and 2 x Fuel (much faster)
?? 2 x O2 never used, or 1x might be broken
?? (when I tried to install Linux or NetBSD
?? on an O2, it powered off and would never power
?? back on; OpenBSD proved easier to install) 
?O2 running OpenBSD, used to run Irix
?? should also be viable for NetBSD, Linux
?Fuel running Irix, could also run OpenBSD
?Fuel is much much faster.
?Irix you can bootstrap up to gcc by using some
? seemingly accidentally there C compiler. 

?
IA64:
?2x; was able to run Linux (Debian) on both.
?Probably viable for VMS, HP-UX, FreeBSD,
?? though I attempted HP-UX and FreeBSD, no luck.
?I might keep one of these.
?One of them lacks video out, must install over serial console.
I think 2U form factors (certainly boxy); heavy 


HPPA:
? one machine, was able to run Linux and HP-UX on it
? no video out, must install over serial console
? 1U or 2U 
? HP-UX can be bootstrapped up to current gcc using in-box K&R cc (via gcc 3.x).


AMD64:
?one Sun workstation, some decent specs


PPC64:
?iMac G5, running Darwin, should be viable for others (e.g. Linux)
?
?
PPC64:
? IBM pSeries workstation; running AIX 5.3, should be viable for others (e.g. Linux)
? This machine seemed to overheat and poweroff, e.g. when building gcc, but
? I did manage to get it working pretty well.


Alpha:
?3x or 4x.
?I only ever tried to use one of them and it didn't seem to work.
?2 are "workstation" size, 2 are the nicer smaller DS10L.


68K/Mac:
? 2x that I don't anticipate anything happening with.
? 
? 
I can also probably spare some Mac/PPC laptops.
? One of which is broken.
? 

I'd rather not lose too much on shipping. But flexible.
I'd rather ship as much as possible to same place. But flexible.
I'd rather reserve right of return, in case I get more space and time,
? but the odds of this mattering is generally decreasing.
? 

Rather than wiping and pulling hard drives, I'll probably just
change SSH keys.


Thanks and sorry of this is off-topic.
?- Jay




 		 	   		  

From wagner at elegosoft.com  Tue Oct  5 12:35:45 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 05 Oct 2010 12:35:45 +0200
Subject: [M3devel] compilation failure on Solaris
Message-ID: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>

There are segmentation faults during compilation of Lex.m3, see:

http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console

=== package m3-libs/libm3 ===
  +++ cm3 -build  
-DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS  && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'   
+++
../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
   m3_backend => 4
m3cc (aka cm3cg) failed compiling: Lex.mc
../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
   m3_backend => 4
m3cc (aka cm3cg) failed compiling: FmtBuf.mc

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From dragisha at m3w.org  Tue Oct  5 15:32:30 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 05 Oct 2010 15:32:30 +0200
Subject: [M3devel] m3gap.... what is it and what does this mean?
Message-ID: <1286285550.3514.20.camel@boromir.m3w.org>

(gdb) p event
$1 = {type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 = 
    {<No data fields>}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {<No data fields>}, 
  string = 0xa <Address 0xa out of bounds>, hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {<No data fields>}}


 VAR
   event: Gdk.EventKey;

  EventKey = RECORD 
    type: EventType;
    window: WindowStar;
    send_event: char;
    time: unsigned_long_int;  
    state: unsigned_int;
    keyval: unsigned_int;
    length: int;
    string: char_star;
    hardware_keycode: unsigned_short_int;
    group: unsigned_char;
  END;

also with m3gdb....

(m3gdb) p event
$1 = {4type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x0,
send_event = 0 '\000', 
  _m3gap_136_56 = {<No data fields>}, time = 49, state = -937844736,
keyval = 32616, length = 23801648, 
  _m3gap_352_32 = {<No data fields>}, string = 0x7f68c839be10 "\001
\000", hardware_keycode = 0, group = 0 '\000', 
  _m3gap_472_40 = {<No data fields>}}

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Tue Oct  5 16:48:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 14:48:41 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286285550.3514.20.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>
Message-ID: <COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>


Hey, look, until August, stock gdb never showed any fields!

The front does layout, it might tell the backend:

struct {
? integer a at offset 4, size 4
? integer b at offset 12, size 4
}

in which case the backend will generate a "gap" field at offset 8, size 4

I suspect we might not have to generate the fields.
I'm nervous that the backend might do its own layout and move up b to offset 8 otherwise.
And there was other code in the backing doing similar.

We are in complete control of the name.
If you want we can call it "_m3_padding_for_alignment"
or "-m3_nothing_to_see_here"
or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)

?- Jay




----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Tue, 5 Oct 2010 15:32:30 +0200
> Subject: [M3devel] m3gap.... what is it and what does this mean?
>
> (gdb) p event
> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 =
> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {},
> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>
>
> VAR
> event: Gdk.EventKey;
>
> EventKey = RECORD
> type: EventType;
> window: WindowStar;
> send_event: char;
> time: unsigned_long_int;
> state: unsigned_int;
> keyval: unsigned_int;
> length: int;
> string: char_star;
> hardware_keycode: unsigned_short_int;
> group: unsigned_char;
> END;
>
> also with m3gdb....
>
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> send_event = 0 '\000',
> _m3gap_136_56 = {}, time = 49, state = -937844736,
> keyval = 32616, length = 23801648,
> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
> \000", hardware_keycode = 0, group = 0 '\000',
> _m3gap_472_40 = {}}
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From rodney_bates at lcwb.coop  Tue Oct  5 21:26:41 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 05 Oct 2010 14:26:41 -0500
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	<COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>
Message-ID: <4CAB7BF1.3050801@lcwb.coop>



Jay K wrote:
> Hey, look, until August, stock gdb never showed any fields!
> 
> The front does layout, it might tell the backend:
> 
> struct {
>   integer a at offset 4, size 4
>   integer b at offset 12, size 4
> }
> 
> in which case the backend will generate a "gap" field at offset 8, size 4
> 
> I suspect we might not have to generate the fields.
> I'm nervous that the backend might do its own layout and move up b to offset 8 otherwise.
> And there was other code in the backing doing similar.
> 
> We are in complete control of the name.
> If you want we can call it "_m3_padding_for_alignment"
> or "-m3_nothing_to_see_here"
> or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)

I doubt it, but they might need to be valid linker identifiers.  If there is a
character that is not legal in Modula-3 identifiers but legal here, it would be nice
to use it in generated things like this.  Then a debugger could normally suppress
displaying it, yet not be fooled by a Modula-3 programmer's actually declaring, e.g.,
_m3gap_8_56 in source code.  There are other places this comes up.

> 
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> From: dragisha at m3w.org
>> To: m3devel at elegosoft.com
>> Date: Tue, 5 Oct 2010 15:32:30 +0200
>> Subject: [M3devel] m3gap.... what is it and what does this mean?
>>
>> (gdb) p event
>> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 =
>> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {},
>> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>>
>>
>> VAR
>> event: Gdk.EventKey;
>>
>> EventKey = RECORD
>> type: EventType;
>> window: WindowStar;
>> send_event: char;
>> time: unsigned_long_int;
>> state: unsigned_int;
>> keyval: unsigned_int;
>> length: int;
>> string: char_star;
>> hardware_keycode: unsigned_short_int;
>> group: unsigned_char;
>> END;
>>
>> also with m3gdb....
>>
>> (m3gdb) p event
>> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
>> send_event = 0 '\000',
>> _m3gap_136_56 = {}, time = 49, state = -937844736,
>> keyval = 32616, length = 23801648,
>> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
>> \000", hardware_keycode = 0, group = 0 '\000',
>> _m3gap_472_40 = {}}
>>
>> --
>> Dragi?a Duri? 
>>
>  		 	   		  


From rodney_bates at lcwb.coop  Tue Oct  5 21:29:22 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 05 Oct 2010 14:29:22 -0500
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286285550.3514.20.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>
Message-ID: <4CAB7C92.7040305@lcwb.coop>

Are the gdb and m3gdb prints for the same value of 'event'?   Several of the fields show different
values.

Dragi?a Duri? wrote:
> (gdb) p event
> $1 = {type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 = 
>     {<No data fields>}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {<No data fields>}, 
>   string = 0xa <Address 0xa out of bounds>, hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {<No data fields>}}
> 
> 
>  VAR
>    event: Gdk.EventKey;
> 
>   EventKey = RECORD 
>     type: EventType;
>     window: WindowStar;
>     send_event: char;
>     time: unsigned_long_int;  
>     state: unsigned_int;
>     keyval: unsigned_int;
>     length: int;
>     string: char_star;
>     hardware_keycode: unsigned_short_int;
>     group: unsigned_char;
>   END;
> 
> also with m3gdb....
> 
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x0,
> send_event = 0 '\000', 
>   _m3gap_136_56 = {<No data fields>}, time = 49, state = -937844736,
> keyval = 32616, length = 23801648, 
>   _m3gap_352_32 = {<No data fields>}, string = 0x7f68c839be10 "\001
> \000", hardware_keycode = 0, group = 0 '\000', 
>   _m3gap_472_40 = {<No data fields>}}
> 


From hosking at cs.purdue.edu  Tue Oct  5 22:04:06 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 5 Oct 2010 16:04:06 -0400
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <4CAB7BF1.3050801@lcwb.coop>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	<COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>
	<4CAB7BF1.3050801@lcwb.coop>
Message-ID: <291C297F-27A1-4F27-9D67-2F0C11ED1F3A@cs.purdue.edu>

M3 ids cannot begin with "_".

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 5 Oct 2010, at 15:26, Rodney M. Bates wrote:

> 
> 
> Jay K wrote:
>> Hey, look, until August, stock gdb never showed any fields!
>> The front does layout, it might tell the backend:
>> struct {
>>  integer a at offset 4, size 4
>>  integer b at offset 12, size 4
>> }
>> in which case the backend will generate a "gap" field at offset 8, size 4
>> I suspect we might not have to generate the fields.
>> I'm nervous that the backend might do its own layout and move up b to offset 8 otherwise.
>> And there was other code in the backing doing similar.
>> We are in complete control of the name.
>> If you want we can call it "_m3_padding_for_alignment"
>> or "-m3_nothing_to_see_here"
>> or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)
> 
> I doubt it, but they might need to be valid linker identifiers.  If there is a
> character that is not legal in Modula-3 identifiers but legal here, it would be nice
> to use it in generated things like this.  Then a debugger could normally suppress
> displaying it, yet not be fooled by a Modula-3 programmer's actually declaring, e.g.,
> _m3gap_8_56 in source code.  There are other places this comes up.
> 
>> - Jay
>> ----------------------------------------
>>> From: dragisha at m3w.org
>>> To: m3devel at elegosoft.com
>>> Date: Tue, 5 Oct 2010 15:32:30 +0200
>>> Subject: [M3devel] m3gap.... what is it and what does this mean?
>>> 
>>> (gdb) p event
>>> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event = 0 '\000', _m3gap_136_56 =
>>> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024, _m3gap_352_32 = {},
>>> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>>> 
>>> 
>>> VAR
>>> event: Gdk.EventKey;
>>> 
>>> EventKey = RECORD
>>> type: EventType;
>>> window: WindowStar;
>>> send_event: char;
>>> time: unsigned_long_int;
>>> state: unsigned_int;
>>> keyval: unsigned_int;
>>> length: int;
>>> string: char_star;
>>> hardware_keycode: unsigned_short_int;
>>> group: unsigned_char;
>>> END;
>>> 
>>> also with m3gdb....
>>> 
>>> (m3gdb) p event
>>> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
>>> send_event = 0 '\000',
>>> _m3gap_136_56 = {}, time = 49, state = -937844736,
>>> keyval = 32616, length = 23801648,
>>> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
>>> \000", hardware_keycode = 0, group = 0 '\000',
>>> _m3gap_472_40 = {}}
>>> 
>>> --
>>> Dragi?a Duri? 
>> 		 	   		  

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

From dragisha at m3w.org  Tue Oct  5 22:58:54 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Tue, 05 Oct 2010 22:58:54 +0200
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <4CAB7C92.7040305@lcwb.coop>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	<4CAB7C92.7040305@lcwb.coop>
Message-ID: <1286312334.3514.35.camel@boromir.m3w.org>

It was same debugging path, but event is X event, so...

On Tue, 2010-10-05 at 14:29 -0500, Rodney M. Bates wrote:
> Are the gdb and m3gdb prints for the same value of 'event'?   Several
> of the fields show different
> values.
> 
> Dragi?a Duri? wrote:
> > (gdb) p event 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Wed Oct  6 00:53:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 22:53:56 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286312334.3514.35.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, <4CAB7C92.7040305@lcwb.coop>,
	<1286312334.3514.35.camel@boromir.m3w.org>
Message-ID: <COL101-W17C90050417FE64E79E72E66D0@phx.gbl>


1) Let's not be too quick to assume the new debugging stuff is correct.
? I just started it in August, in response to internal compiler errors passing records by value on SPARC64.
? (seems unrelated, but it isn't; there isn't really "debug" stuff in gcc backends, there are merely
? types in the trees, and we were creating records with size but not fields at all, pretty poor
? gcc citizens imho...)
? Though they probably often are correct. I know the level of indirection is sometimes wrong though, like
? on record parameters.

2) The numbers are bit offset and bit size, so not as big as you might think.
I can make them trivially byte offsets, if they are multiples of 8, at the cost
of possible confusion when they aren't.
Or they can just be called _m3gap1, _m3gap2, numbered either per-unit
or per-type.

I could also try not putting them in at all, but merely bumping the offset
of the next field in the same way as current and hoping backend
doesn't relayout and move them toward the start.

?- Jay



----------------------------------------
> From: dragisha at m3w.org
> To: rodney_bates at lcwb.coop
> Date: Tue, 5 Oct 2010 22:58:54 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... what is it and what does this mean?
>
> It was same debugging path, but event is X event, so...
>
> On Tue, 2010-10-05 at 14:29 -0500, Rodney M. Bates wrote:
> > Are the gdb and m3gdb prints for the same value of 'event'? Several
> > of the fields show different
> > values.
> >
> > Dragi?a Duri? wrote:
> > > (gdb) p event
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Wed Oct  6 00:49:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 5 Oct 2010 22:49:57 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <291C297F-27A1-4F27-9D67-2F0C11ED1F3A@cs.purdue.edu>
References: <1286285550.3514.20.camel@boromir.m3w.org>,
	<COL101-w65E49BCAEBA332A903FC85E66D0@phx.gbl>,
	<4CAB7BF1.3050801@lcwb.coop>,
	<291C297F-27A1-4F27-9D67-2F0C11ED1F3A@cs.purdue.edu>
Message-ID: <COL101-W55C57390007CB07BEF6C3DE66D0@phx.gbl>


The names are generated in the backend.
Use of leading underscore is therefore good -- it can't clash with "real" data.

?- Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Tue, 5 Oct 2010 16:04:06 -0400
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... what is it and what does this mean?
>
> M3 ids cannot begin with "_".
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On 5 Oct 2010, at 15:26, Rodney M. Bates wrote:
>
>
>
> Jay K wrote:
> Hey, look, until August, stock gdb never showed any fields!
> The front does layout, it might tell the backend:
> struct {
> integer a at offset 4, size 4
> integer b at offset 12, size 4
> }
> in which case the backend will generate a "gap" field at offset 8, size 4
> I suspect we might not have to generate the fields.
> I'm nervous that the backend might do its own layout and move up b to
> offset 8 otherwise.
> And there was other code in the backing doing similar.
> We are in complete control of the name.
> If you want we can call it "_m3_padding_for_alignment"
> or "-m3_nothing_to_see_here"
> or "http://m3.org/faq1.html" (not sure they have to be valid C identifiers)
>
> I doubt it, but they might need to be valid linker identifiers. If
> there is a
> character that is not legal in Modula-3 identifiers but legal here, it
> would be nice
> to use it in generated things like this. Then a debugger could
> normally suppress
> displaying it, yet not be fooled by a Modula-3 programmer's actually
> declaring, e.g.,
> _m3gap_8_56 in source code. There are other places this comes up.
>
> - Jay
> ----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Tue, 5 Oct 2010 15:32:30 +0200
> Subject: [M3devel] m3gap.... what is it and what does this mean?
>
> (gdb) p event
> $1 = {type = 8 '\b', _m3gap_8_56 = {}, window = 0x6924c0, send_event =
> 0 '\000', _m3gap_136_56 =
> {}, time = 210453397504, state = 1, keyval = 0, length = 22953024,
> _m3gap_352_32 = {},
> string = 0xa , hardware_keycode = 0, group = 0 '\000', _m3gap_472_40 = {}}
>
>
> VAR
> event: Gdk.EventKey;
>
> EventKey = RECORD
> type: EventType;
> window: WindowStar;
> send_event: char;
> time: unsigned_long_int;
> state: unsigned_int;
> keyval: unsigned_int;
> length: int;
> string: char_star;
> hardware_keycode: unsigned_short_int;
> group: unsigned_char;
> END;
>
> also with m3gdb....
>
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> send_event = 0 '\000',
> _m3gap_136_56 = {}, time = 49, state = -937844736,
> keyval = 32616, length = 23801648,
> _m3gap_352_32 = {}, string = 0x7f68c839be10 "\001
> \000", hardware_keycode = 0, group = 0 '\000',
> _m3gap_472_40 = {}}
>
> --
> Dragi?a Duri?
>
>
 		 	   		  

From dragisha at m3w.org  Wed Oct  6 01:48:56 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 06 Oct 2010 01:48:56 +0200
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <COL101-W17C90050417FE64E79E72E66D0@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	, <4CAB7C92.7040305@lcwb.coop>,
	<1286312334.3514.35.camel@boromir.m3w.org>
	<COL101-W17C90050417FE64E79E72E66D0@phx.gbl>
Message-ID: <1286322536.3514.41.camel@boromir.m3w.org>

They are nice as they are, as long as debugging works. Information on
alignment is good to have.

On Tue, 2010-10-05 at 22:53 +0000, Jay K wrote:
> 2) The numbers are bit offset and bit size, so not as big as you might
> think.
> I can make them trivially byte offsets, if they are multiples of 8, at
> the cost
> of possible confusion when they aren't.
> Or they can just be called _m3gap1, _m3gap2, numbered either per-unit
> or per-type.
> 
> I could also try not putting them in at all, but merely bumping the
> offset
> of the next field in the same way as current and hoping backend
> doesn't relayout and move them toward the start. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Wed Oct  6 03:10:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 01:10:30 +0000
Subject: [M3devel] m3gap.... what is it and what does this mean?
In-Reply-To: <1286322536.3514.41.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>,,
	<4CAB7C92.7040305@lcwb.coop>, ,
	<1286312334.3514.35.camel@boromir.m3w.org>,
	<COL101-W17C90050417FE64E79E72E66D0@phx.gbl>,
	<1286322536.3514.41.camel@boromir.m3w.org>
Message-ID: <COL101-W27409A49660B73E76EDE1DE66E0@phx.gbl>


Implied tedious request:
  write some code
  including printing out the values with IO. or RTIO.
  step through
  view in debugger
  verify it all matches
  think about how enums should appear, they are perhaps too short now
  Try subranges, enums, objects, records, fixed arrays, open arrays.
    I'm positive not all of that works though, e.g. arrays for certain. 
 
 - Jay



----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Wed, 6 Oct 2010 01:48:56 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... what is it and what does this mean?
>
> They are nice as they are, as long as debugging works. Information on
> alignment is good to have.
>
> On Tue, 2010-10-05 at 22:53 +0000, Jay K wrote:
> > 2) The numbers are bit offset and bit size, so not as big as you might
> > think.
> > I can make them trivially byte offsets, if they are multiples of 8, at
> > the cost
> > of possible confusion when they aren't.
> > Or they can just be called _m3gap1, _m3gap2, numbered either per-unit
> > or per-type.
> >
> > I could also try not putting them in at all, but merely bumping the
> > offset
> > of the next field in the same way as current and hoping backend
> > doesn't relayout and move them toward the start.
> --
> Dragi?a Duri? 
> 		 	   		  

From jay.krell at cornell.edu  Wed Oct  6 11:20:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 09:20:14 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
Message-ID: <COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>


I see. It occurs even on a cross build.
It should be better now -- by avoiding certain large changes on this platform.
A C generating backend is getting ever more tempting..

?- Jay

----------------------------------------
> Date: Tue, 5 Oct 2010 12:35:45 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] compilation failure on Solaris
>
> There are segmentation faults during compilation of Lex.m3, see:
>
> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>
> === package m3-libs/libm3 ===
> +++ cm3 -build
> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> +++
> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> m3_backend => 4
> m3cc (aka cm3cg) failed compiling: Lex.mc
> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> m3_backend => 4
> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From hosking at cs.purdue.edu  Wed Oct  6 15:07:31 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 09:07:31 -0400
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>
Message-ID: <766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>

Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"?  I am wary of special-casing builds of a system as complex as gcc depending on target.

On 6 Oct 2010, at 05:20, Jay K wrote:

> 
> I see. It occurs even on a cross build.
> It should be better now -- by avoiding certain large changes on this platform.
> A C generating backend is getting ever more tempting..
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Tue, 5 Oct 2010 12:35:45 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] compilation failure on Solaris
>> 
>> There are segmentation faults during compilation of Lex.m3, see:
>> 
>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>> 
>> === package m3-libs/libm3 ===
>> +++ cm3 -build
>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
>> +++
>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> m3_backend => 4
>> m3cc (aka cm3cg) failed compiling: Lex.mc
>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> m3_backend => 4
>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>> 
>> Olaf
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>> 
> 		 	   		  



From jay.krell at cornell.edu  Wed Oct  6 15:24:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 13:24:30 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>
Message-ID: <COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>


It isn't easy. I'm lazy.
I flip one thing and voila cm3 crashes.
I compare e.g. m3core before/after, but there are many changes.

There have been significant changes since August -- starting to provide half decent type information in the trees.
The ramifications of this are potentially very large, and they seem to vary per-target.

Used to be records never had any fields, just a size. That was probably good at tying the compiler's hands,
but it was bad for debugging with regular gdb.

Plus the long time we used volatile.
Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
until relatively recently (nested functions that gcc thinks are unused, but are referenced
from the module data).

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 09:07:31 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] compilation failure on Solaris
>
> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
>
> On 6 Oct 2010, at 05:20, Jay K wrote:
>
> >
> > I see. It occurs even on a cross build.
> > It should be better now -- by avoiding certain large changes on this platform.
> > A C generating backend is getting ever more tempting..
> >
> > - Jay
> >
> > ----------------------------------------
> >> Date: Tue, 5 Oct 2010 12:35:45 +0200
> >> From: wagner at elegosoft.com
> >> To: m3devel at elegosoft.com
> >> Subject: [M3devel] compilation failure on Solaris
> >>
> >> There are segmentation faults during compilation of Lex.m3, see:
> >>
> >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> >> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
> >>
> >> === package m3-libs/libm3 ===
> >> +++ cm3 -build
> >> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> >> +++
> >> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See for instructions.
> >> m3_backend => 4
> >> m3cc (aka cm3cg) failed compiling: Lex.mc
> >> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See for instructions.
> >> m3_backend => 4
> >> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
> >>
> >> Olaf
> >> --
> >> Olaf Wagner -- elego Software Solutions GmbH
> >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>
> >
>
 		 	   		  

From jay.krell at cornell.edu  Wed Oct  6 15:30:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 13:30:00 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
Message-ID: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>


some random notes

Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
? Easy test is to run cm3 without a neighboring cm3.cfg and the error
? is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg

Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
? Same easy test, but it crashes upon first attempt to raise an exception.

Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
? NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
? 
Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
? Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.

Meanwhile I think many other targets are working ok with 4.5.
Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Wed Oct  6 16:34:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 10:34:45 -0400
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>
Message-ID: <43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>

I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated. 

Sent from my iPhone

On Oct 6, 2010, at 9:24 AM, Jay K <jay.krell at cornell.edu> wrote:

> Plus the long time we used volatile.
> Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
> until relatively recently (nested functions that gcc thinks are unused, but are referenced
> from the module data).
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 6 Oct 2010 09:07:31 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] compilation failure on Solaris
>> 
>> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
>> 
>> On 6 Oct 2010, at 05:20, Jay K wrote:
>> 
>>> 
>>> I see. It occurs even on a cross build.
>>> It should be better now -- by avoiding certain large changes on this platform.
>>> A C generating backend is getting ever more tempting..
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
>>>> From: wagner at elegosoft.com
>>>> To: m3devel at elegosoft.com
>>>> Subject: [M3devel] compilation failure on Solaris
>>>> 
>>>> There are segmentation faults during compilation of Lex.m3, see:
>>>> 
>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>>>> 
>>>> === package m3-libs/libm3 ===
>>>> +++ cm3 -build
>>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
>>>> +++
>>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
>>>> Please submit a full bug report,
>>>> with preprocessed source if appropriate.
>>>> See for instructions.
>>>> m3_backend => 4
>>>> m3cc (aka cm3cg) failed compiling: Lex.mc
>>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
>>>> Please submit a full bug report,
>>>> with preprocessed source if appropriate.
>>>> See for instructions.
>>>> m3_backend => 4
>>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>>>> 
>>>> Olaf
>>>> --
>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>>> 
>>> 
>> 
>                         


From hosking at cs.purdue.edu  Wed Oct  6 16:48:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 10:48:21 -0400
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
Message-ID: <3A129857-64E9-49C3-BEA3-71BFFCE4E282@cs.purdue.edu>



On 6 Oct 2010, at 09:30, Jay K wrote:

> 
> some random notes
> 
> Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
>   Easy test is to run cm3 without a neighboring cm3.cfg and the error
>   is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg

Used not to break.  I did test this at one point.

> Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
>   Same easy test, but it crashes upon first attempt to raise an exception.
> 
> Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
>   NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
>   
> Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
>   Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> 
> Meanwhile I think many other targets are working ok with 4.5.
> Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Wed Oct  6 17:03:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 15:03:02 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>,
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>,
	<43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
Message-ID: <COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>


There is only one instance in the tree currently that I know of, and I write it relatively recently.
? (And I can workaround it easily by unnesting the function.)
Perhaps it was never seen before?

Here it is:


jbook2:src jay$ edit lego/ZChassisVBT.m3
jbook2:src jay$ pwd
/dev2/cm3/m3-ui/vbtkit/src


PROCEDURE NewBtn (uglyPosixText, win32ppm: TEXT; shadow: Shadow.T): VBT.T =

PROCEDURE Posix (t: TEXT; shadow: Shadow.T): VBT.T =
? BEGIN
??? WITH textVBT = TextVBT.New (t) DO
????? TextVBT.SetFont (textVBT, Font.BuiltIn, shadow);
????? RETURN NEW (ShadowedFeedbackVBT.T).init (textVBT, shadow)
??? END
? END Posix;

PROCEDURE Win32 (name: TEXT; shadow: Shadow.T): VBT.T =
? VAR
??? pm := VBTKitResources.GetPixmap (name);
??? pixvbt := NEW(PixmapVBT.T).init(pm, halign := 0.0, valign := 0.0,
??????????????????????????????? op := PaintOp.Copy);
? BEGIN
??? RETURN NEW (ShadowedFeedbackVBT.T).init (pixvbt, shadow)
? END Win32;

? BEGIN
??? CASE Compiler.ThisOS OF
????? | Compiler.OS.POSIX => RETURN Posix(uglyPosixText, shadow);
????? | Compiler.OS.WIN32 => RETURN Win32(win32ppm, shadow);
??? END;
? END NewBtn;

Of course, between Posix and Win32, one is dead.

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 10:34:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] compilation failure on Solaris
>
> I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated.
>
> Sent from my iPhone
>
> On Oct 6, 2010, at 9:24 AM, Jay K  wrote:
>
> > Plus the long time we used volatile.
> > Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
> > until relatively recently (nested functions that gcc thinks are unused, but are referenced
> > from the module data).
> >
> > - Jay
> >
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Wed, 6 Oct 2010 09:07:31 -0400
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] compilation failure on Solaris
> >>
> >> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
> >>
> >> On 6 Oct 2010, at 05:20, Jay K wrote:
> >>
> >>>
> >>> I see. It occurs even on a cross build.
> >>> It should be better now -- by avoiding certain large changes on this platform.
> >>> A C generating backend is getting ever more tempting..
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
> >>>> From: wagner at elegosoft.com
> >>>> To: m3devel at elegosoft.com
> >>>> Subject: [M3devel] compilation failure on Solaris
> >>>>
> >>>> There are segmentation faults during compilation of Lex.m3, see:
> >>>>
> >>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> >>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
> >>>>
> >>>> === package m3-libs/libm3 ===
> >>>> +++ cm3 -build
> >>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> >>>> +++
> >>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> >>>> Please submit a full bug report,
> >>>> with preprocessed source if appropriate.
> >>>> See for instructions.
> >>>> m3_backend => 4
> >>>> m3cc (aka cm3cg) failed compiling: Lex.mc
> >>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> >>>> Please submit a full bug report,
> >>>> with preprocessed source if appropriate.
> >>>> See for instructions.
> >>>> m3_backend => 4
> >>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
> >>>>
> >>>> Olaf
> >>>> --
> >>>> Olaf Wagner -- elego Software Solutions GmbH
> >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> >>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>>>
> >>>
> >>
> >
 		 	   		  

From dragisha at m3w.org  Wed Oct  6 18:49:54 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 06 Oct 2010 18:49:54 +0200
Subject: [M3devel] GCC version, danger zone
In-Reply-To: <COL101-W6126EB7972E7D5607EA24FE66E0@phx.gbl>
References: <20101006104543.A18DB2474003@birch.elegosoft.com>
	, , <D487B610-E139-4791-83C6-9B9824A34DD9@cs.purdue.edu>
	, <COL101-W63B0B6343EF7EBA88858AFE66E0@phx.gbl>
	, <074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu>
	<COL101-W6126EB7972E7D5607EA24FE66E0@phx.gbl>
Message-ID: <1286383794.3849.5.camel@boromir.m3w.org>

GNU Pascal team capitulated on GCC backend, due to galloping changes GCC
team is making.
SRC people fixed SRCM3 on particular GCC release just because their
change rate is rampant.
Let's be careful to not go way of GNU Pascal -> way of dodo. Please!

On Wed, 2010-10-06 at 15:06 +0000, Jay K wrote:
> 
> Let me maybe get 4.5.1 working before -O3.
> Granted..I agree it was probably working as recently as the recent
> release.
> What changed since then? In the 4.3 tree? ==> I moved from 4.3.0 to
> 4.3.5.
> So if we want to find -O3 working, it is probably there.
> 
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From hosking at cs.purdue.edu  Wed Oct  6 19:50:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 13:50:00 -0400
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>,
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>,
	<43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
	<COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>
Message-ID: <C1A1128F-9125-4499-896C-F63D22455DBC@cs.purdue.edu>

This code has been around a long time.


On 6 Oct 2010, at 11:03, Jay K wrote:

> 
> There is only one instance in the tree currently that I know of, and I write it relatively recently.
>   (And I can workaround it easily by unnesting the function.)
> Perhaps it was never seen before?
> 
> Here it is:
> 
> 
> jbook2:src jay$ edit lego/ZChassisVBT.m3
> jbook2:src jay$ pwd
> /dev2/cm3/m3-ui/vbtkit/src
> 
> 
> PROCEDURE NewBtn (uglyPosixText, win32ppm: TEXT; shadow: Shadow.T): VBT.T =
> 
> PROCEDURE Posix (t: TEXT; shadow: Shadow.T): VBT.T =
>   BEGIN
>     WITH textVBT = TextVBT.New (t) DO
>       TextVBT.SetFont (textVBT, Font.BuiltIn, shadow);
>       RETURN NEW (ShadowedFeedbackVBT.T).init (textVBT, shadow)
>     END
>   END Posix;
> 
> PROCEDURE Win32 (name: TEXT; shadow: Shadow.T): VBT.T =
>   VAR
>     pm := VBTKitResources.GetPixmap (name);
>     pixvbt := NEW(PixmapVBT.T).init(pm, halign := 0.0, valign := 0.0,
>                                 op := PaintOp.Copy);
>   BEGIN
>     RETURN NEW (ShadowedFeedbackVBT.T).init (pixvbt, shadow)
>   END Win32;
> 
>   BEGIN
>     CASE Compiler.ThisOS OF
>       | Compiler.OS.POSIX => RETURN Posix(uglyPosixText, shadow);
>       | Compiler.OS.WIN32 => RETURN Win32(win32ppm, shadow);
>     END;
>   END NewBtn;
> 
> Of course, between Posix and Win32, one is dead.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 6 Oct 2010 10:34:45 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] compilation failure on Solaris
>> 
>> I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated.
>> 
>> Sent from my iPhone
>> 
>> On Oct 6, 2010, at 9:24 AM, Jay K  wrote:
>> 
>>> Plus the long time we used volatile.
>>> Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
>>> until relatively recently (nested functions that gcc thinks are unused, but are referenced
>>> from the module data).
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 6 Oct 2010 09:07:31 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] compilation failure on Solaris
>>>> 
>>>> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
>>>> 
>>>> On 6 Oct 2010, at 05:20, Jay K wrote:
>>>> 
>>>>> 
>>>>> I see. It occurs even on a cross build.
>>>>> It should be better now -- by avoiding certain large changes on this platform.
>>>>> A C generating backend is getting ever more tempting..
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
>>>>>> From: wagner at elegosoft.com
>>>>>> To: m3devel at elegosoft.com
>>>>>> Subject: [M3devel] compilation failure on Solaris
>>>>>> 
>>>>>> There are segmentation faults during compilation of Lex.m3, see:
>>>>>> 
>>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
>>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
>>>>>> 
>>>>>> === package m3-libs/libm3 ===
>>>>>> +++ cm3 -build
>>>>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
>>>>>> +++
>>>>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
>>>>>> Please submit a full bug report,
>>>>>> with preprocessed source if appropriate.
>>>>>> See for instructions.
>>>>>> m3_backend => 4
>>>>>> m3cc (aka cm3cg) failed compiling: Lex.mc
>>>>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
>>>>>> Please submit a full bug report,
>>>>>> with preprocessed source if appropriate.
>>>>>> See for instructions.
>>>>>> m3_backend => 4
>>>>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
>>>>>> 
>>>>>> Olaf
>>>>>> --
>>>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>>>>> 
>>>>> 
>>>> 
>>> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed Oct  6 19:53:48 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 6 Oct 2010 13:53:48 -0400
Subject: [M3devel] GCC version, danger zone
In-Reply-To: <1286383794.3849.5.camel@boromir.m3w.org>
References: <20101006104543.A18DB2474003@birch.elegosoft.com> , ,
	<D487B610-E139-4791-83C6-9B9824A34DD9@cs.purdue.edu> ,
	<COL101-W63B0B6343EF7EBA88858AFE66E0@phx.gbl> ,
	<074A9418-7240-4678-B3CE-C98C2C8B1908@cs.purdue.edu>
	<COL101-W6126EB7972E7D5607EA24FE66E0@phx.gbl>
	<1286383794.3849.5.camel@boromir.m3w.org>
Message-ID: <5D4465D1-C461-4739-A288-6EA6E94F966C@cs.purdue.edu>

Good point!

On 6 Oct 2010, at 12:49, Dragi?a Duri? wrote:

> GNU Pascal team capitulated on GCC backend, due to galloping changes GCC
> team is making.
> SRC people fixed SRCM3 on particular GCC release just because their
> change rate is rampant.
> Let's be careful to not go way of GNU Pascal -> way of dodo. Please!
> 
> On Wed, 2010-10-06 at 15:06 +0000, Jay K wrote:
>> 
>> Let me maybe get 4.5.1 working before -O3.
>> Granted..I agree it was probably working as recently as the recent
>> release.
>> What changed since then? In the 4.3 tree? ==> I moved from 4.3.0 to
>> 4.3.5.
>> So if we want to find -O3 working, it is probably there.
>> 
>> 
> -- 
> Dragi?a Duri? <dragisha at m3w.org>



From dragisha at m3w.org  Wed Oct  6 22:40:12 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 06 Oct 2010 22:40:12 +0200
Subject: [M3devel] static linking of some C libs...
Message-ID: <1286397612.7401.0.camel@boromir.m3w.org>

I would like to statically link only some C libs. How to do it?
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu Oct  7 00:37:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 22:37:35 +0000
Subject: [M3devel] compilation failure on Solaris
In-Reply-To: <C1A1128F-9125-4499-896C-F63D22455DBC@cs.purdue.edu>
References: <20101005123545.odplouoykgg48gok@mail.elegosoft.com>,
	<COL101-W445A8FC6C61F2F5BE1C485E66E0@phx.gbl>,
	<766C88F4-D0CB-4874-9625-49E9D2737A02@cs.purdue.edu>,
	<COL101-W52C435A8287FEDDC057CCEE66E0@phx.gbl>,
	<43D43754-41D9-4104-B0BA-BFCA8C0FAEC6@cs.purdue.edu>
	<COL101-W200B30085554967FBAFDD8E66E0@phx.gbl>,
	<C1A1128F-9125-4499-896C-F63D22455DBC@cs.purdue.edu>
Message-ID: <COL101-W266E6E413DA34C43D955B2E66E0@phx.gbl>


The construct that leads the backend when compiling "unit at a time" to throw out referenced nested function dates to only May 2010.

http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-ui/vbtkit/src/lego/ZChassisVBT.m3

?- Jay


----------------------------------------
> Subject: Re: [M3devel] compilation failure on Solaris
> From: hosking at cs.purdue.edu
> Date: Wed, 6 Oct 2010 13:50:00 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> This code has been around a long time.
>
>
> On 6 Oct 2010, at 11:03, Jay K wrote:
>
> >
> > There is only one instance in the tree currently that I know of, and I write it relatively recently.
> > (And I can workaround it easily by unnesting the function.)
> > Perhaps it was never seen before?
> >
> > Here it is:
> >
> >
> > jbook2:src jay$ edit lego/ZChassisVBT.m3
> > jbook2:src jay$ pwd
> > /dev2/cm3/m3-ui/vbtkit/src
> >
> >
> > PROCEDURE NewBtn (uglyPosixText, win32ppm: TEXT; shadow: Shadow.T): VBT.T =
> >
> > PROCEDURE Posix (t: TEXT; shadow: Shadow.T): VBT.T =
> > BEGIN
> > WITH textVBT = TextVBT.New (t) DO
> > TextVBT.SetFont (textVBT, Font.BuiltIn, shadow);
> > RETURN NEW (ShadowedFeedbackVBT.T).init (textVBT, shadow)
> > END
> > END Posix;
> >
> > PROCEDURE Win32 (name: TEXT; shadow: Shadow.T): VBT.T =
> > VAR
> > pm := VBTKitResources.GetPixmap (name);
> > pixvbt := NEW(PixmapVBT.T).init(pm, halign := 0.0, valign := 0.0,
> > op := PaintOp.Copy);
> > BEGIN
> > RETURN NEW (ShadowedFeedbackVBT.T).init (pixvbt, shadow)
> > END Win32;
> >
> > BEGIN
> > CASE Compiler.ThisOS OF
> > | Compiler.OS.POSIX => RETURN Posix(uglyPosixText, shadow);
> > | Compiler.OS.WIN32 => RETURN Win32(win32ppm, shadow);
> > END;
> > END NewBtn;
> >
> > Of course, between Posix and Win32, one is dead.
> >
> > - Jay
> >
> >
> > ----------------------------------------
> >> From: hosking at cs.purdue.edu
> >> Date: Wed, 6 Oct 2010 10:34:45 -0400
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] compilation failure on Solaris
> >>
> >> I remember fixing that one a long time back. I think I added a new check (possible new use of volarile or addressed) to make sure they weren't eliminated.
> >>
> >> Sent from my iPhone
> >>
> >> On Oct 6, 2010, at 9:24 AM, Jay K wrote:
> >>
> >>> Plus the long time we used volatile.
> >>> Plus that even with volatile, things still didn't work with -O3, just that I didn't find a case
> >>> until relatively recently (nested functions that gcc thinks are unused, but are referenced
> >>> from the module data).
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> From: hosking at cs.purdue.edu
> >>>> Date: Wed, 6 Oct 2010 09:07:31 -0400
> >>>> To: jay.krell at cornell.edu
> >>>> CC: m3devel at elegosoft.com
> >>>> Subject: Re: [M3devel] compilation failure on Solaris
> >>>>
> >>>> Why can't we just understand the problem and fix it rather than avoiding "certain large changes on this platform"? I am wary of special-casing builds of a system as complex as gcc depending on target.
> >>>>
> >>>> On 6 Oct 2010, at 05:20, Jay K wrote:
> >>>>
> >>>>>
> >>>>> I see. It occurs even on a cross build.
> >>>>> It should be better now -- by avoiding certain large changes on this platform.
> >>>>> A C generating backend is getting ever more tempting..
> >>>>>
> >>>>> - Jay
> >>>>>
> >>>>> ----------------------------------------
> >>>>>> Date: Tue, 5 Oct 2010 12:35:45 +0200
> >>>>>> From: wagner at elegosoft.com
> >>>>>> To: m3devel at elegosoft.com
> >>>>>> Subject: [M3devel] compilation failure on Solaris
> >>>>>>
> >>>>>> There are segmentation faults during compilation of Lex.m3, see:
> >>>>>>
> >>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current10s/219/console
> >>>>>> http://hudson.modula3.com:8080/job/cm3-current-build-SOLsun-opencsw-current9s/107/console
> >>>>>>
> >>>>>> === package m3-libs/libm3 ===
> >>>>>> +++ cm3 -build
> >>>>>> -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3' $RARGS && cm3 -ship $RARGS -DROOT='/home/m3hudson/current9s/workspace/cm3-current-build-SOLsun-opencsw-current9s/cm3'
> >>>>>> +++
> >>>>>> ../src/fmtlex/Lex.m3:492: internal compiler error: Segmentation Fault
> >>>>>> Please submit a full bug report,
> >>>>>> with preprocessed source if appropriate.
> >>>>>> See for instructions.
> >>>>>> m3_backend => 4
> >>>>>> m3cc (aka cm3cg) failed compiling: Lex.mc
> >>>>>> ../src/fmtlex/FmtBuf.m3:226: internal compiler error: Segmentation Fault
> >>>>>> Please submit a full bug report,
> >>>>>> with preprocessed source if appropriate.
> >>>>>> See for instructions.
> >>>>>> m3_backend => 4
> >>>>>> m3cc (aka cm3cg) failed compiling: FmtBuf.mc
> >>>>>>
> >>>>>> Olaf
> >>>>>> --
> >>>>>> Olaf Wagner -- elego Software Solutions GmbH
> >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >>>>>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> >>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 00:52:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 22:52:22 +0000
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <1286397612.7401.0.camel@boromir.m3w.org>
References: <1286397612.7401.0.camel@boromir.m3w.org>
Message-ID: <COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>


I don't have a good answer here.
I have some bad ones: Only have static libraries.
We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.


Microsoft link doesn't really have the notion you ask for. It just has libraries.
It has a better model imho.
It never links to .so/.dll files.
It links to .libs.
Those .libs might be "normal" static ones with real code in them,
or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
(In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
.libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
once you know to look.)


The Unix linkers have a wierd model where they probe around like mad and are willing
to "link" to an .so/.dll file with no .lib/.a in sight.
It is good in terms of "self description" but bad in terms of conflating runtime and tools.


In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
is the norm.


The import libraries are to a large extent a small transform of the .dll files, so, well,
there is something to the Unix model. It isn't completely crazy, it seems better at first
maybe but it is wierd and inferior ultimately.


So, for Windows, which I suspect you are talking about, point the linker at a static library.
The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
environment variable, or the -libpath command line option. But it doesn't make its own
static vs. dynamic decisions or probe around in a way to do so, except to the extent
that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
full paths to .lib files, what you ask for is what you get.


(I do suspect you are asking specifically about Windows.)


Modula-3 does something slightly tricky in order to allow static and dynamic and
for it to later chose. It makes static libraries for everything: foo.lib.sa.
"sa" = standalone.
And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
If it is build_standalone, it renames foo.lib.sa to foo.lib.


Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.


All this is done by cm3/the config file though. No trickery or probing in the linker.


It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
And how there is m3core.dll, but no m3quake.dll.


I does basically identical for Unix even.
Part of the Unix story is using -fPIC always.
It is an inefficiency sometimes, but imho worth it.
I wish Windows code was always position independent, rather than worry
about base addresses and relocation costs (prior to Vista, relocs were
applied to entire .dll at load, killing demand paging and page sharing;
as of Vista, they are applied at page-in, which preserves demand paging
but still loses on page sharing).


?-Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Wed, 6 Oct 2010 22:40:12 +0200
> Subject: [M3devel] static linking of some C libs...
>
> I would like to statically link only some C libs. How to do it?
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 01:20:12 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 6 Oct 2010 23:20:12 +0000
Subject: [M3devel] gcc 4.5 + AMD64_SOLARIS fyi
Message-ID: <COL101-W18C65A5BA10B392652EBDFE66E0@phx.gbl>


m3cc (aka cm3cg) failed compiling: Unicode.mc
new source -> compiling Address.i3
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated


occurs in pretty much every file

?- Jay
 		 	   		  

From dragisha at m3w.org  Thu Oct  7 07:58:55 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 07 Oct 2010 07:58:55 +0200
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>
References: <1286397612.7401.0.camel@boromir.m3w.org>
	<COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>
Message-ID: <1286431135.7401.13.camel@boromir.m3w.org>

gcc GSTABS_TO_WARN_COMMON_LD_ARGS -Wl,-rpath,/usr/local/cm3/bin/../lib  -o MYPGM  _m3main.o MYOBJS /usr/local/cm3/pkg/openssl/AMD64_LINUX/libhm3openssl.a /usr/lib64/libssl.a /usr/lib64/libcrypto.a -lz -L/usr/local/cm3/pkg/libm3/AMD64_LINUX -lm3 -L/usr/local/cm3/pkg/m3core/AMD64_LINUX -lm3core -lm -ldl -lkrb5 -pthread

This is what I made.... Manually of course.
      * build_standalone() in m3makefile ;
      * cm3 -commands (this fails at linking because it cannot succeed
        if fully static, but I get original linking command I edit
        later)
      * cd ../AMD64_LINUX
      * command from first line...

build_standalone() is just setting build_shared somewhere in Builder.m3
to FALSE.. So it's all or nothing. What we need is a way to specify
(best would be in main app m3makefile, so installed libraries can be
static on demand) what libraries we need static. With that info passed
through m3makefile, current quake code can produce custom command.

If nobody has time/will to do this, I'll do it after I deliver my
current project.

On Wed, 2010-10-06 at 22:52 +0000, Jay K wrote:
> I don't have a good answer here.
> I have some bad ones: Only have static libraries.
> We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.
> 
> 
> Microsoft link doesn't really have the notion you ask for. It just has libraries.
> It has a better model imho.
> It never links to .so/.dll files.
> It links to .libs.
> Those .libs might be "normal" static ones with real code in them,
> or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
> (In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
> .libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
> It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
> However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
> once you know to look.)
> 
> 
> The Unix linkers have a wierd model where they probe around like mad and are willing
> to "link" to an .so/.dll file with no .lib/.a in sight.
> It is good in terms of "self description" but bad in terms of conflating runtime and tools.
> 
> 
> In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
> is the norm.
> 
> 
> The import libraries are to a large extent a small transform of the .dll files, so, well,
> there is something to the Unix model. It isn't completely crazy, it seems better at first
> maybe but it is wierd and inferior ultimately.
> 
> 
> So, for Windows, which I suspect you are talking about, point the linker at a static library.
> The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
> environment variable, or the -libpath command line option. But it doesn't make its own
> static vs. dynamic decisions or probe around in a way to do so, except to the extent
> that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
> full paths to .lib files, what you ask for is what you get.
> 
> 
> (I do suspect you are asking specifically about Windows.)
> 
> 
> Modula-3 does something slightly tricky in order to allow static and dynamic and
> for it to later chose. It makes static libraries for everything: foo.lib.sa.
> "sa" = standalone.
> And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
> If it is build_standalone, it renames foo.lib.sa to foo.lib.
> 
> 
> Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
> If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.
> 
> 
> All this is done by cm3/the config file though. No trickery or probing in the linker.
> 
> 
> It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
> And how there is m3core.dll, but no m3quake.dll.
> 
> 
> I does basically identical for Unix even.
> Part of the Unix story is using -fPIC always.
> It is an inefficiency sometimes, but imho worth it.
> I wish Windows code was always position independent, rather than worry
> about base addresses and relocation costs (prior to Vista, relocs were
> applied to entire .dll at load, killing demand paging and page sharing;
> as of Vista, they are applied at page-in, which preserves demand paging
> but still loses on page sharing).
> 
> 
>  -Jay
> 
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: m3devel at elegosoft.com
> > Date: Wed, 6 Oct 2010 22:40:12 +0200
> > Subject: [M3devel] static linking of some C libs...
> >
> > I would like to statically link only some C libs. How to do it?
> > --
> > Dragi?a Duri? 
> >
>  		 	   		  

-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu Oct  7 08:13:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 06:13:54 +0000
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <1286431135.7401.13.camel@boromir.m3w.org>
References: <1286397612.7401.0.camel@boromir.m3w.org>,
	<COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>,
	<1286431135.7401.13.camel@boromir.m3w.org>
Message-ID: <COL101-W5E9607FC46DFC67A99F8EE66F0@phx.gbl>


Right.
What you want something like:
import_standalone("libfoo")
or import_static("libfoo")

shouldn't be too hard.
Just stick libfoo in some global hashtable and then when linking looks for libfoo.so vs. libfoo.a, it can use that to guide.

That is assuming libfoo is built by Modula-3 and that there are both.
If it is a C library, you'll have to do something else.

<rant>
I find Unix link command lines extremely confusing and very likely both
? having too many and too few features. What with options being in effect
until end of command line, or maybe not, or being able to turn them off/on as you go,
making it all ridiculously order-dependent. You really want to "attach" options to parameters,
or just have a dramatically simpler model and fewer options.
With Windows it is very simple. You give it a full path to a .lib or a leaf path and %LIB% is searched.
There are no options that apply to some or all .libs. It is much much much simpler, and provides
all that you need/want.
All the more reason, perhaps, to write our linker in Modula-3!
? (That'd be a great piece of a cross build story...but is a ton ton ton of work.)
Unix linkers also have a ridiculous number of confusing options like -z origin (why?), -z now (the
default on Windows, unless you use -delayload), -z combreloc, etc. etc. etc. including man pages
that list options that aren't really there because the loader doesn't support them (.e.g -z origin
historically on NetBSD).

Not to mention the historical defaults that were obviously wrong at the time and now have all been since deprecated.
? e.g. the flat namespace, leading to more confusing an inefficiency. As if emulating static linking
? was of such paramount importance that everything could be made worse in support of this misguided direction...
</rant>


?- Jay


----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 7 Oct 2010 07:58:55 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] static linking of some C libs...
>
> gcc GSTABS_TO_WARN_COMMON_LD_ARGS -Wl,-rpath,/usr/local/cm3/bin/../lib -o MYPGM _m3main.o MYOBJS /usr/local/cm3/pkg/openssl/AMD64_LINUX/libhm3openssl.a /usr/lib64/libssl.a /usr/lib64/libcrypto.a -lz -L/usr/local/cm3/pkg/libm3/AMD64_LINUX -lm3 -L/usr/local/cm3/pkg/m3core/AMD64_LINUX -lm3core -lm -ldl -lkrb5 -pthread
>
> This is what I made.... Manually of course.
> * build_standalone() in m3makefile ;
> * cm3 -commands (this fails at linking because it cannot succeed
> if fully static, but I get original linking command I edit
> later)
> * cd ../AMD64_LINUX
> * command from first line...
>
> build_standalone() is just setting build_shared somewhere in Builder.m3
> to FALSE.. So it's all or nothing. What we need is a way to specify
> (best would be in main app m3makefile, so installed libraries can be
> static on demand) what libraries we need static. With that info passed
> through m3makefile, current quake code can produce custom command.
>
> If nobody has time/will to do this, I'll do it after I deliver my
> current project.
>
> On Wed, 2010-10-06 at 22:52 +0000, Jay K wrote:
> > I don't have a good answer here.
> > I have some bad ones: Only have static libraries.
> > We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.
> >
> >
> > Microsoft link doesn't really have the notion you ask for. It just has libraries.
> > It has a better model imho.
> > It never links to .so/.dll files.
> > It links to .libs.
> > Those .libs might be "normal" static ones with real code in them,
> > or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
> > (In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
> > .libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
> > It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
> > However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
> > once you know to look.)
> >
> >
> > The Unix linkers have a wierd model where they probe around like mad and are willing
> > to "link" to an .so/.dll file with no .lib/.a in sight.
> > It is good in terms of "self description" but bad in terms of conflating runtime and tools.
> >
> >
> > In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
> > is the norm.
> >
> >
> > The import libraries are to a large extent a small transform of the .dll files, so, well,
> > there is something to the Unix model. It isn't completely crazy, it seems better at first
> > maybe but it is wierd and inferior ultimately.
> >
> >
> > So, for Windows, which I suspect you are talking about, point the linker at a static library.
> > The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
> > environment variable, or the -libpath command line option. But it doesn't make its own
> > static vs. dynamic decisions or probe around in a way to do so, except to the extent
> > that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
> > full paths to .lib files, what you ask for is what you get.
> >
> >
> > (I do suspect you are asking specifically about Windows.)
> >
> >
> > Modula-3 does something slightly tricky in order to allow static and dynamic and
> > for it to later chose. It makes static libraries for everything: foo.lib.sa.
> > "sa" = standalone.
> > And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
> > If it is build_standalone, it renames foo.lib.sa to foo.lib.
> >
> >
> > Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
> > If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.
> >
> >
> > All this is done by cm3/the config file though. No trickery or probing in the linker.
> >
> >
> > It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
> > And how there is m3core.dll, but no m3quake.dll.
> >
> >
> > I does basically identical for Unix even.
> > Part of the Unix story is using -fPIC always.
> > It is an inefficiency sometimes, but imho worth it.
> > I wish Windows code was always position independent, rather than worry
> > about base addresses and relocation costs (prior to Vista, relocs were
> > applied to entire .dll at load, killing demand paging and page sharing;
> > as of Vista, they are applied at page-in, which preserves demand paging
> > but still loses on page sharing).
> >
> >
> > -Jay
> >
> > ----------------------------------------
> > > From: dragisha at m3w.org
> > > To: m3devel at elegosoft.com
> > > Date: Wed, 6 Oct 2010 22:40:12 +0200
> > > Subject: [M3devel] static linking of some C libs...
> > >
> > > I would like to statically link only some C libs. How to do it?
> > > --
> > > Dragi?a Duri?
> > >
> >
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 08:21:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 06:21:14 +0000
Subject: [M3devel] gcc 4.5 + AMD64_SOLARIS fyi
In-Reply-To: <COL101-W18C65A5BA10B392652EBDFE66E0@phx.gbl>
References: <COL101-W18C65A5BA10B392652EBDFE66E0@phx.gbl>
Message-ID: <COL101-W48F1E07E8067647F7D42A7E66F0@phx.gbl>


Stupid autoconf just breaks things.

??? gcc_GAS_CHECK_FEATURE([.quad directive],
????? gcc_cv_as_ix86_quad,,,
????? [.quad 0],,
????? [AC_DEFINE(HAVE_AS_IX86_QUAD, 1,
??????? [Define if your assembler supports the .quad directive.])])

added in gcc 4.5 breaks things nicely.
Fix will be to just hardcode  gcc_cv_as_ix86_quad as true in src/m3makefile when doing cross builds to AMD64_SOLARIS.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: gcc 4.5 + AMD64_SOLARIS fyi
> Date: Wed, 6 Oct 2010 23:20:12 +0000
>
>
> m3cc (aka cm3cg) failed compiling: Unicode.mc
> new source -> compiling Address.i3
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
> ../src/types/Address.i3:31:0: error: initializer for integer/fixed-point value is too complicated
>
>
> occurs in pretty much every file
>
>  - Jay
>
 		 	   		  

From dragisha at m3w.org  Thu Oct  7 09:16:36 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 07 Oct 2010 09:16:36 +0200
Subject: [M3devel] static linking of some C libs...
In-Reply-To: <COL101-W5E9607FC46DFC67A99F8EE66F0@phx.gbl>
References: <1286397612.7401.0.camel@boromir.m3w.org>
	,<COL101-W352EB6A91DB74B6E8BCA1E66E0@phx.gbl>
	,<1286431135.7401.13.camel@boromir.m3w.org>
	<COL101-W5E9607FC46DFC67A99F8EE66F0@phx.gbl>
Message-ID: <1286435796.7401.21.camel@boromir.m3w.org>

Of course it's built with Modula-3, and if it's pure C lib - then make a
"placeholder" Modula-3 lib just to keep it "under quake". That way we
will have full control on options, resolving,,, per platform where
differences occur. As opposed to autocrap way and m4 (it's not Modula-4,
don't jump :).

GCC is a hell, and linking "logic" is just a tip of the iceberg. Order
dependency is least of problems. Thus said - I am against Modula-3
linker - our resources are too scarce to fix everything.

import_standalone() would fill static_libs hash, just like import fills
imported_libs, and build_standalone() will just move everything from
imported_libs to static_libs before m3_link continues. Looks clean.

On Thu, 2010-10-07 at 06:13 +0000, Jay K wrote:
> 
> Right.
> What you want something like:
> import_standalone("libfoo")
> or import_static("libfoo")
> 
> shouldn't be too hard.
> Just stick libfoo in some global hashtable and then when linking looks
> for libfoo.so vs. libfoo.a, it can use that to guide.
> 
> That is assuming libfoo is built by Modula-3 and that there are both.
> If it is a C library, you'll have to do something else.
> 
> <rant>
> I find Unix link command lines extremely confusing and very likely
> both
>   having too many and too few features. What with options being in
> effect
> until end of command line, or maybe not, or being able to turn them
> off/on as you go,
> making it all ridiculously order-dependent. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu Oct  7 10:15:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 08:15:39 +0000
Subject: [M3devel] static chain: what does D do?
In-Reply-To: <COL101-W40B78A4BD59FE234DD80F6E66E0@phx.gbl>
References: <20101006090354.BD40E2474003@birch.elegosoft.com>, ,
	<2E507E51-9600-47B0-8849-99297B3841E9@cs.purdue.edu>,
	<COL101-W54E93A9A943E33E99177CCE66E0@phx.gbl>,
	<4E2BB803-F603-4D9B-8E06-6B7D73CC7392@cs.purdue.edu>,
	<COL101-W40B78A4BD59FE234DD80F6E66E0@phx.gbl>
Message-ID: <COL101-W8344853307806904E5F6AE66F0@phx.gbl>



> > Hmm. Do we know what Pascal/Ada/D and friends do in this instance?
>
>
> Good point. I don't know.

Here is part of the answer:

jbook2:d jay$ grep -i chain p* | grep DEF
patch-apple-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_EXPR, "static_chain_expr", tcc_expression, 1)
patch-apple-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_DECL, "static_chain_decl", tcc_expression, 0)
patch-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_EXPR, "static_chain_expr", tcc_expression, 1)
patch-gcc-4.0.x:+ DEFTREECODE (STATIC_CHAIN_DECL, "static_chain_decl", tcc_expression, 0)
patch-gcc-4.1.x:+ DEFTREECODE (STATIC_CHAIN_EXPR, "static_chain_expr", tcc_expression, 1)
patch-gcc-4.1.x:+ DEFTREECODE (STATIC_CHAIN_DECL, "static_chain_decl", tcc_expression, 0)


interesting.
We had one tree code. They add two.
Their changes are more involved than ours.

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 11:45:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 09:45:49 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>
Message-ID: <COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>


Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
I suspect we are underusing volatile.
e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
? The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.

I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
all MODIFY_EXPR. There is probably redundancy here.

Notice that even the original volatization was incomplete.
It volatized current function's current temporaries/locals, but not others declared after
any call to setjmp. I fixed that at some point.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: random notes: gcc 4.5, sparc, etc.
> Date: Wed, 6 Oct 2010 13:30:00 +0000
>
>
> some random notes
>
> Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
>   Easy test is to run cm3 without a neighboring cm3.cfg and the error
>   is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
>
> Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
>   Same easy test, but it crashes upon first attempt to raise an exception.
>
> Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
>   NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
>
> Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
>   Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
>
> Meanwhile I think many other targets are working ok with 4.5.
> Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
>
>  - Jay
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 13:22:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 11:22:28 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>,
	<COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>
Message-ID: <COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>


oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Thu, 7 Oct 2010 09:45:49 +0000
>
>
> Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> I suspect we are underusing volatile.
> e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
>   The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
>
> I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> all MODIFY_EXPR. There is probably redundancy here.
>
> Notice that even the original volatization was incomplete.
> It volatized current function's current temporaries/locals, but not others declared after
> any call to setjmp. I fixed that at some point.
>
>  - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: random notes: gcc 4.5, sparc, etc.
> > Date: Wed, 6 Oct 2010 13:30:00 +0000
> >
> >
> > some random notes
> >
> > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> >
> > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > Same easy test, but it crashes upon first attempt to raise an exception.
> >
> > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> >
> > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> >
> > Meanwhile I think many other targets are working ok with 4.5.
> > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> >
> > - Jay
> >
>
 		 	   		  

From jay.krell at cornell.edu  Thu Oct  7 22:02:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 7 Oct 2010 20:02:11 +0000
Subject: [M3devel] Solaris/amd64
Message-ID: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>


There's a complete Solaris/amd64 in /home/jkrell/cm3.amd64 on the opencsw machines having used 4.5.1 backend.
? I can't test the X apps I think (not sure of the remoting).
Would be good to get that in Hudson.

?- Jay


 		 	   		  

From wagner at elegosoft.com  Fri Oct  8 10:28:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 08 Oct 2010 10:28:24 +0200
Subject: [M3devel] Solaris/amd64
In-Reply-To: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
References: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
Message-ID: <20101008102824.61nbtaufk8gowk4s@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> There's a complete Solaris/amd64 in /home/jkrell/cm3.amd64 on the   
> opencsw machines having used 4.5.1 backend.
> ? I can't test the X apps I think (not sure of the remoting).
> Would be good to get that in Hudson.

Is anybody else interested in setting up those jobs? Should not be
difficult, mostly a matter of copy&paste in HTML forms and doing
some one-time bootstrapping to create the necessary directories
and CM3 installations.

It would be great if others acquire some experience with our Hudson
build and regression tests.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Oct  8 13:44:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 11:44:57 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>,
	<COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>,
	<COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>
Message-ID: <COL101-W53AFBBF14A6AC6EA7745F2E6500@phx.gbl>


For the record:
Still, no luck. Replacing MxConfig.ms from 4.3 seems to let it get further.
Or maybe it was M*.
Problem seems to be that when M3File__IsReadable returns, $l7 gets zeroed.

But I'm going to try another hack.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Thu, 7 Oct 2010 11:22:28 +0000
>
>
> oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.
>
>  - Jay
>
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > Date: Thu, 7 Oct 2010 09:45:49 +0000
> >
> >
> > Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> > I suspect we are underusing volatile.
> > e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
> > The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
> >
> > I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> > all MODIFY_EXPR. There is probably redundancy here.
> >
> > Notice that even the original volatization was incomplete.
> > It volatized current function's current temporaries/locals, but not others declared after
> > any call to setjmp. I fixed that at some point.
> >
> > - Jay
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Subject: random notes: gcc 4.5, sparc, etc.
> > > Date: Wed, 6 Oct 2010 13:30:00 +0000
> > >
> > >
> > > some random notes
> > >
> > > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> > >
> > > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > > Same easy test, but it crashes upon first attempt to raise an exception.
> > >
> > > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> > >
> > > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> > >
> > > Meanwhile I think many other targets are working ok with 4.5.
> > > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> > >
> > > - Jay
> > >
> >
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  8 16:17:00 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 08 Oct 2010 16:17:00 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286285550.3514.20.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>
Message-ID: <1286547420.7401.43.camel@boromir.m3w.org>

WindowStar is 
TYPE
  Window = RECORD
    user_data: void_star
  END;
  WindowStar = UNTRACED REF Window;

and this whole record is
typedef struct {
  GdkEventType type;
  GdkWindow *window;
  gint8 send_event;
  guint32 time;
  guint state;
  guint keyval;
  gint length;
  gchar *string;
  guint16 hardware_keycode;
  guint8 group;
  guint is_modifier : 1;
} GdkEventKey;

in C.

It's Modula-3 BYTESIZE is 64, and C sizeof() is 56. window field is aligned at 8 bytes (thank you Jay for m3gap 8_56!) and C's GdkWindow * is aligned at 4 bytes.

As I don't use window field I'll split it in two placeholder int's, but this is, IMO, interesting point.

dd

On Tue, 2010-10-05 at 15:32 +0200, Dragi?a Duri? wrote:
>   EventKey = RECORD 
>     type: EventType;
>     window: WindowStar;
>     send_event: char;
>     time: unsigned_long_int;  
>     state: unsigned_int;
>     keyval: unsigned_int;
>     length: int;
>     string: char_star;
>     hardware_keycode: unsigned_short_int;
>     group: unsigned_char;
>   END;
> 
> also with m3gdb....
> 
> (m3gdb) p event
> $1 = {4type = 8 '\b', _m3gap_8_56 = {<No data fields>}, window = 0x0,
> send_event = 0 '\000', 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  8 20:36:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 18:36:44 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286547420.7401.43.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>,
	<1286547420.7401.43.camel@boromir.m3w.org>
Message-ID: <COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>


I may have broken this, a while ago. I may have relaxed all the alignments long ago.
We have very little interfacing with C now and most of that is with our own C,
where I avoid small types.
We have had at least temporary problems related to our rules being sort of too strict.
? The need for -munaligned-double or such. (which reminds me I should try that again).
? Where our rules were ok but gcc's default for to align stuff more.
? Where our layout and gcc's didn't agree.

How bad would it be to generate or write a C layer that copies stuff into "idealized" structs?
? Where the types are all INTEGER or LONGINT or pointers.

?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Fri, 8 Oct 2010 16:17:00 +0200
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> WindowStar is
> TYPE
> Window = RECORD
> user_data: void_star
> END;
> WindowStar = UNTRACED REF Window;
>
> and this whole record is
> typedef struct {
> GdkEventType type;
> GdkWindow *window;
> gint8 send_event;
> guint32 time;
> guint state;
> guint keyval;
> gint length;
> gchar *string;
> guint16 hardware_keycode;
> guint8 group;
> guint is_modifier : 1;
> } GdkEventKey;
>
> in C.
>
> It's Modula-3 BYTESIZE is 64, and C sizeof() is 56. window field is aligned at 8 bytes (thank you Jay for m3gap 8_56!) and C's GdkWindow * is aligned at 4 bytes.
>
> As I don't use window field I'll split it in two placeholder int's, but this is, IMO, interesting point.
>
> dd
>
> On Tue, 2010-10-05 at 15:32 +0200, Dragi?a Duri? wrote:
> > EventKey = RECORD
> > type: EventType;
> > window: WindowStar;
> > send_event: char;
> > time: unsigned_long_int;
> > state: unsigned_int;
> > keyval: unsigned_int;
> > length: int;
> > string: char_star;
> > hardware_keycode: unsigned_short_int;
> > group: unsigned_char;
> > END;
> >
> > also with m3gdb....
> >
> > (m3gdb) p event
> > $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> > send_event = 0 '\000',
> --
> Dragi?a Duri? 
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  8 20:46:56 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 08 Oct 2010 20:46:56 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,<1286547420.7401.43.camel@boromir.m3w.org>
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
Message-ID: <1286563617.7401.68.camel@boromir.m3w.org>

We will always have some friction there... IMO, stricter is better, with
maybe a pragma there... preceding variable/field name, fixing align,
like

  EventKey = RECORD
    type: EventType;
    <* ALIGN 4 *> window: WindowStar;
    ...
  END;

As for GCC... Does it not make alignment exception, or something, to
reference non-aligned pointer on AMD64?

Idealized structs... I didn't follow you there, probably I missed
something earlier on list.

On Fri, 2010-10-08 at 18:36 +0000, Jay K wrote:
> I may have broken this, a while ago. I may have relaxed all the
> alignments long ago.
> We have very little interfacing with C now and most of that is with
> our own C,
> where I avoid small types.
> We have had at least temporary problems related to our rules being
> sort of too strict.
>   The need for -munaligned-double or such. (which reminds me I should
> try that again).
>   Where our rules were ok but gcc's default for to align stuff more.
>   Where our layout and gcc's didn't agree.
> 
> How bad would it be to generate or write a C layer that copies stuff
> into "idealized" structs?
>   Where the types are all INTEGER or LONGINT or pointers. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Fri Oct  8 21:00:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 19:00:14 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286563617.7401.68.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, ,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>,
	<1286563617.7401.68.camel@boromir.m3w.org>
Message-ID: <COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>


Idealized is you grow everything to LONGINT or INTEGER and sort by size,
and copy back/forth with C. There will be no padding, guaranteed.

?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 8 Oct 2010 20:46:56 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> We will always have some friction there... IMO, stricter is better, with
> maybe a pragma there... preceding variable/field name, fixing align,
> like
>
> EventKey = RECORD
> type: EventType;
> <* ALIGN 4 *> window: WindowStar;
> ...
> END;
>
> As for GCC... Does it not make alignment exception, or something, to
> reference non-aligned pointer on AMD64?
>
> Idealized structs... I didn't follow you there, probably I missed
> something earlier on list.
>
> On Fri, 2010-10-08 at 18:36 +0000, Jay K wrote:
> > I may have broken this, a while ago. I may have relaxed all the
> > alignments long ago.
> > We have very little interfacing with C now and most of that is with
> > our own C,
> > where I avoid small types.
> > We have had at least temporary problems related to our rules being
> > sort of too strict.
> > The need for -munaligned-double or such. (which reminds me I should
> > try that again).
> > Where our rules were ok but gcc's default for to align stuff more.
> > Where our layout and gcc's didn't agree.
> >
> > How bad would it be to generate or write a C layer that copies stuff
> > into "idealized" structs?
> > Where the types are all INTEGER or LONGINT or pointers.
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Fri Oct  8 21:01:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 19:01:09 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
Message-ID: <COL101-W339845E597D706AF5EEE09E6500@phx.gbl>


Or make all field references be via function calls to C.
Very good option imho.
Like how I access DIR->d_name.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org; m3devel at elegosoft.com
> Subject: RE: [M3devel] m3gap.... it's an alignment issue
> Date: Fri, 8 Oct 2010 18:36:44 +0000
>
>
> I may have broken this, a while ago. I may have relaxed all the alignments long ago.
> We have very little interfacing with C now and most of that is with our own C,
> where I avoid small types.
> We have had at least temporary problems related to our rules being sort of too strict.
>   The need for -munaligned-double or such. (which reminds me I should try that again).
>   Where our rules were ok but gcc's default for to align stuff more.
>   Where our layout and gcc's didn't agree.
>
> How bad would it be to generate or write a C layer that copies stuff into "idealized" structs?
>   Where the types are all INTEGER or LONGINT or pointers.
>
>  - Jay
>
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: m3devel at elegosoft.com
> > Date: Fri, 8 Oct 2010 16:17:00 +0200
> > Subject: Re: [M3devel] m3gap.... it's an alignment issue
> >
> > WindowStar is
> > TYPE
> > Window = RECORD
> > user_data: void_star
> > END;
> > WindowStar = UNTRACED REF Window;
> >
> > and this whole record is
> > typedef struct {
> > GdkEventType type;
> > GdkWindow *window;
> > gint8 send_event;
> > guint32 time;
> > guint state;
> > guint keyval;
> > gint length;
> > gchar *string;
> > guint16 hardware_keycode;
> > guint8 group;
> > guint is_modifier : 1;
> > } GdkEventKey;
> >
> > in C.
> >
> > It's Modula-3 BYTESIZE is 64, and C sizeof() is 56. window field is aligned at 8 bytes (thank you Jay for m3gap 8_56!) and C's GdkWindow * is aligned at 4 bytes.
> >
> > As I don't use window field I'll split it in two placeholder int's, but this is, IMO, interesting point.
> >
> > dd
> >
> > On Tue, 2010-10-05 at 15:32 +0200, Dragi?a Duri? wrote:
> > > EventKey = RECORD
> > > type: EventType;
> > > window: WindowStar;
> > > send_event: char;
> > > time: unsigned_long_int;
> > > state: unsigned_int;
> > > keyval: unsigned_int;
> > > length: int;
> > > string: char_star;
> > > hardware_keycode: unsigned_short_int;
> > > group: unsigned_char;
> > > END;
> > >
> > > also with m3gdb....
> > >
> > > (m3gdb) p event
> > > $1 = {4type = 8 '\b', _m3gap_8_56 = {}, window = 0x0,
> > > send_event = 0 '\000',
> > --
> > Dragi?a Duri?
> >
>
 		 	   		  

From jay.krell at cornell.edu  Fri Oct  8 21:03:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 8 Oct 2010 19:03:19 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286563617.7401.68.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, ,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>,
	<1286563617.7401.68.camel@boromir.m3w.org>
Message-ID: <COL101-W63F9F601EF463A07A12CE1E6500@phx.gbl>


Gcc does nothing special. There are "never" alignment exceptions on x86.
? Things might run slower. There is a control bit in the processor to make
? it more strict but surely nobody sets it.
? Some interlocked and maybe sse/sse2/3/4 intructions have alignment requirements.
?We either have to go pains to match it precisely, and have silent memory
? corruption if we fail. Or give up and don't really try.
By relaxed I meant larger alignments. You might call this more strict.

?- Jay


----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 8 Oct 2010 20:46:56 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> We will always have some friction there... IMO, stricter is better, with
> maybe a pragma there... preceding variable/field name, fixing align,
> like
>
> EventKey = RECORD
> type: EventType;
> <* ALIGN 4 *> window: WindowStar;
> ...
> END;
>
> As for GCC... Does it not make alignment exception, or something, to
> reference non-aligned pointer on AMD64?
>
> Idealized structs... I didn't follow you there, probably I missed
> something earlier on list.
>
> On Fri, 2010-10-08 at 18:36 +0000, Jay K wrote:
> > I may have broken this, a while ago. I may have relaxed all the
> > alignments long ago.
> > We have very little interfacing with C now and most of that is with
> > our own C,
> > where I avoid small types.
> > We have had at least temporary problems related to our rules being
> > sort of too strict.
> > The need for -munaligned-double or such. (which reminds me I should
> > try that again).
> > Where our rules were ok but gcc's default for to align stuff more.
> > Where our layout and gcc's didn't agree.
> >
> > How bad would it be to generate or write a C layer that copies stuff
> > into "idealized" structs?
> > Where the types are all INTEGER or LONGINT or pointers.
> --
> Dragi?a Duri? 
>
 		 	   		  

From dragisha at m3w.org  Fri Oct  8 21:06:37 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Fri, 08 Oct 2010 21:06:37 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W339845E597D706AF5EEE09E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,<1286547420.7401.43.camel@boromir.m3w.org>
	,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	<COL101-W339845E597D706AF5EEE09E6500@phx.gbl>
Message-ID: <1286564797.7401.70.camel@boromir.m3w.org>

Not a bad idea, if we are generating wrapper code... To write all that
by hand... I am shuddering at thought :)

On Fri, 2010-10-08 at 19:01 +0000, Jay K wrote:
> 
> Or make all field references be via function calls to C.
> Very good option imho.
> Like how I access DIR->d_name. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sat Oct  9 23:53:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 9 Oct 2010 21:53:18 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>, ,
	<1286547420.7401.43.camel@boromir.m3w.org>,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>,
	<1286563617.7401.68.camel@boromir.m3w.org>,
	<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
Message-ID: <COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>


> Idealized is you grow everything to LONGINT or INTEGER and sort by size,
> and copy back/forth with C. There will be no padding, guaranteed.

I sort of made up these rules btw, and then sort alphabetically.
And for good measure, during initialization, you can
pass a value or var/pointer of one of these structs to/from
C/Modula-3 and assert on the other side that it looks as expected.
 
 
For example:
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/TestC.c
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3tests/src/Test.i3
  "CheckFloatsAndTypes"
 
I couldn't find where I call it.
I would be reasonble imho to put in m3core.
 Though the float stuff should be better thought out to have
  a complete but no extra test.
Maybe even passed from main to RTLinker.InitRuntime.
 
This is also done in:
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosixC.c
  function TypeCheck
 
 
To make sure the C and Modula-3 line up.
Note this isn't with "underlying C", but with our own C.
I moved things up a layer to avoid extra copying of struct tm,
and so I could #ifdef the 2 almost identical implementations into one.
 
 
 - Jay 		 	   		  

From dragisha at m3w.org  Sun Oct 10 01:50:43 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 10 Oct 2010 01:50:43 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,,<1286547420.7401.43.camel@boromir.m3w.org>
	,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	,<1286563617.7401.68.camel@boromir.m3w.org>
	,<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
	<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
Message-ID: <1286668243.7401.79.camel@boromir.m3w.org>

Eliminating key phrase being "out own C"...

I understand your approach here, and it's all OK - except it means ultra
extra work for large APIs like Gtk+ I am working with/on. To accomplish
things in our lifetimes, we have to automate things. It all boils down
to "parse .h somehow, and then manipulate AST's to produce pieces of C
and pieces of Modula-3". 

Looks a lot what SWIG does already, and I think it's nice place to
start. Get what they already learned from .h's and produce better
interfacing libraries. More concise and readable, at least.

On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> 
> Note this isn't with "underlying C", but with our own C. 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sun Oct 10 08:52:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Oct 2010 06:52:49 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <1286668243.7401.79.camel@boromir.m3w.org>
References: <1286285550.3514.20.camel@boromir.m3w.org>, , ,
	<1286547420.7401.43.camel@boromir.m3w.org>, ,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>, ,
	<1286563617.7401.68.camel@boromir.m3w.org>, ,
	<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>,
	<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>,
	<1286668243.7401.79.camel@boromir.m3w.org>
Message-ID: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>


Look at what others do?
 
Heck there is a C# binding. You can compile that
and reflect over its metadata.. should be able
to spit back out the original C headers?
 
 
Just Bing for "automate gtk binding"?
 
http://pwet.fr/man/linux/commandes/generate2
http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#autogeneration
 
etc.
 
Someone should make an interface language, that everyone
actually uses!
 
 - Jay



----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Sun, 10 Oct 2010 01:50:43 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gap.... it's an alignment issue
>
> Eliminating key phrase being "out own C"...
>
> I understand your approach here, and it's all OK - except it means ultra
> extra work for large APIs like Gtk+ I am working with/on. To accomplish
> things in our lifetimes, we have to automate things. It all boils down
> to "parse .h somehow, and then manipulate AST's to produce pieces of C
> and pieces of Modula-3".
>
> Looks a lot what SWIG does already, and I think it's nice place to
> start. Get what they already learned from .h's and produce better
> interfacing libraries. More concise and readable, at least.
>
> On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> >
> > Note this isn't with "underlying C", but with our own C.
> --
> Dragi?a Duri? 
> 		 	   		  

From jay.krell at cornell.edu  Sun Oct 10 08:55:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 10 Oct 2010 06:55:41 +0000
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>, , ,
	<1286547420.7401.43.camel@boromir.m3w.org>, ,
	<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>, ,
	<1286563617.7401.68.camel@boromir.m3w.org>, ,
	<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>,
	<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>,
	<1286668243.7401.79.camel@boromir.m3w.org>,
	<COL101-W5840291BB9D967149038BBE6520@phx.gbl>
Message-ID: <COL101-W25D903D0121B17997EDFEEE6520@phx.gbl>


get gtk.defs from pygtk.
 
or
"It's worth noting that the "new way" to do things is with
gobject-introspection rather than a defs file (see pybank, gjs)"
 
etc.
 
 
 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] m3gap.... it's an alignment issue
> Date: Sun, 10 Oct 2010 06:52:49 +0000
>
>
> Look at what others do?
>
> Heck there is a C# binding. You can compile that
> and reflect over its metadata.. should be able
> to spit back out the original C headers?
>
>
> Just Bing for "automate gtk binding"?
>
> http://pwet.fr/man/linux/commandes/generate2
> http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#autogeneration
>
> etc.
>
> Someone should make an interface language, that everyone
> actually uses!
>
> - Jay
>
>
>
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: jay.krell at cornell.edu
> > Date: Sun, 10 Oct 2010 01:50:43 +0200
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] m3gap.... it's an alignment issue
> >
> > Eliminating key phrase being "out own C"...
> >
> > I understand your approach here, and it's all OK - except it means ultra
> > extra work for large APIs like Gtk+ I am working with/on. To accomplish
> > things in our lifetimes, we have to automate things. It all boils down
> > to "parse .h somehow, and then manipulate AST's to produce pieces of C
> > and pieces of Modula-3".
> >
> > Looks a lot what SWIG does already, and I think it's nice place to
> > start. Get what they already learned from .h's and produce better
> > interfacing libraries. More concise and readable, at least.
> >
> > On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> > >
> > > Note this isn't with "underlying C", but with our own C.
> > --
> > Dragi?a Duri?
> > 		 	   		  

From dragisha at m3w.org  Sun Oct 10 09:30:19 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 10 Oct 2010 09:30:19 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,,,<1286547420.7401.43.camel@boromir.m3w.org>
	,,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	,,<1286563617.7401.68.camel@boromir.m3w.org>
	,,<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
	,<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
	,<1286668243.7401.79.camel@boromir.m3w.org>
	<COL101-W5840291BB9D967149038BBE6520@phx.gbl>
Message-ID: <1286695819.7401.88.camel@boromir.m3w.org>

Of course... And I found lots of them uses regexp "parsers"... All
making same mistakes du to an EOL too many. No silver bullet there, but
even if there is one - Gtk+ is one example.

More important library (for me, of course) I am looking at is ffmpeg.
And few others. And their bindingness is not long enough present problem
to be as widely approached as Gtk+ is. 

On Sun, 2010-10-10 at 06:52 +0000, Jay K wrote:
> Look at what others do?
>  
> Heck there is a C# binding. You can compile that
> and reflect over its metadata.. should be able
> to spit back out the original C headers?
>  
> 
> Just Bing for "automate gtk binding"?
>  
> http://pwet.fr/man/linux/commandes/generate2
> http://gtk2-perl.sourceforge.net/doc/binding_howto.pod.html#autogeneration
>  
> etc.
>  
> Someone should make an interface language, that everyone
> actually uses!
>  
>  - Jay
> 
> 
> 
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: jay.krell at cornell.edu
> > Date: Sun, 10 Oct 2010 01:50:43 +0200
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] m3gap.... it's an alignment issue
> >
> > Eliminating key phrase being "out own C"...
> >
> > I understand your approach here, and it's all OK - except it means ultra
> > extra work for large APIs like Gtk+ I am working with/on. To accomplish
> > things in our lifetimes, we have to automate things. It all boils down
> > to "parse .h somehow, and then manipulate AST's to produce pieces of C
> > and pieces of Modula-3".
> >
> > Looks a lot what SWIG does already, and I think it's nice place to
> > start. Get what they already learned from .h's and produce better
> > interfacing libraries. More concise and readable, at least.
> >
> > On Sat, 2010-10-09 at 21:53 +0000, Jay K wrote:
> > >
> > > Note this isn't with "underlying C", but with our own C.
> > --
> > Dragi?a Duri? 
> > 		 	   		  

-- 
Dragi?a Duri? <dragisha at m3w.org>



From dragisha at m3w.org  Sun Oct 10 09:31:38 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 10 Oct 2010 09:31:38 +0200
Subject: [M3devel] m3gap.... it's an alignment issue
In-Reply-To: <COL101-W5840291BB9D967149038BBE6520@phx.gbl>
References: <1286285550.3514.20.camel@boromir.m3w.org>
	,,,<1286547420.7401.43.camel@boromir.m3w.org>
	,,<COL101-W40C467AC5896E9CD4566E0E6500@phx.gbl>
	,,<1286563617.7401.68.camel@boromir.m3w.org>
	,,<COL101-W33E35BE061E57EE23D1441E6500@phx.gbl>
	,<COL101-W4144AAD4578A0834AD8D80E6510@phx.gbl>
	,<1286668243.7401.79.camel@boromir.m3w.org>
	<COL101-W5840291BB9D967149038BBE6520@phx.gbl>
Message-ID: <1286695898.7401.89.camel@boromir.m3w.org>

Someone was, many times. But that didn't catch due to "It works, let's
go on" philosophy many schools are teaching.

On Sun, 2010-10-10 at 06:52 +0000, Jay K wrote:
> Someone should make an interface language, that everyone
> actually uses!
>   
-- 
Dragi?a Duri? <dragisha at m3w.org>



From dam at opencsw.org  Mon Oct 11 21:41:48 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 11 Oct 2010 21:41:48 +0200
Subject: [M3devel] Solaris/amd64
In-Reply-To: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
References: <COL101-W181DB82AC4739614FF312CE66F0@phx.gbl>
Message-ID: <6BC12B5F-5751-4F32-AA6E-8BC5FB8B0304@opencsw.org>

Hi Jay,

Am 07.10.2010 um 22:02 schrieb Jay K:
> There's a complete Solaris/amd64 in /home/jkrell/cm3.amd64 on the  
> opencsw machines having used 4.5.1 backend.
>   I can't test the X apps I think (not sure of the remoting).

Did I set up SSGD (X11-over-https) for you? This should make
redirection easy:
   https://sgd.opencsw.org


Best regards

   -- Dago




From jay.krell at cornell.edu  Tue Oct 12 00:35:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 11 Oct 2010 22:35:29 +0000
Subject: [M3devel] random notes: gcc 4.5, sparc, etc.
In-Reply-To: <COL101-W53AFBBF14A6AC6EA7745F2E6500@phx.gbl>
References: <COL101-W52FB62F9D37B6A586D18E7E66E0@phx.gbl>,
	<COL101-W4970B180D3F97DDF0DB10BE66F0@phx.gbl>,
	<COL101-W15271C2FD7F9FC8AA6850AE66F0@phx.gbl>,
	<COL101-W53AFBBF14A6AC6EA7745F2E6500@phx.gbl>
Message-ID: <COL101-W63F21716075DE7A992C65CE6530@phx.gbl>


This is a really tough one to figure out.
I've tried making everything as returns_twice. No luck.
I'm not doing any optimization anyway.
  Though it looks like some optimizations might be done anyway,
  like converting jumps to jumps to single jump.
  I did some work to make 4.3 and 4.5 match, but not completely, and no luck so far.
 
 
I believe the problem isn't MxConfig per se. It is just that the 4.3
version doesn't use $l7 after calling M3File__IsReadable, so
is ok if $l7 isn't restored correctly.
 
 
I have to figure out, perhaps, where save/restore/return/ta3 store/load
the registers from and if that is getting corrupt.
I had trouble finding details on the SPARC stuff. (too much skimming by me) 
e.g. that the register windows are 16 registers in size,
that every non-leaf function must therefore have a frame of at least 64 bytes.
Er, the windows are actually 24 in size, but they overlap by 8, so 16 registers
might be saved/restored at each frame.
(Aside: I believe one of the flaws here is not register windows per se, but
fixed size register windows; I believe Itanium has effectively
variably sized register windows).
 
 
There's still stuff I don't understand -- how setjmp/longjmp/setcontext work.
 wrt SPARC specifically. I understand them otherwise.
 In a CS class in college I was actually tricked on a test by
 the "implement setjmp/longjmp for SPARC" question. I had implemented
 setjmp/longjmp for 65816 so I was overconfident, and just
 did simple register save/load. The trick at the time
 was explained to be "restore in a loop until the register window
 lines up". However that's not how SPARC longjmp looks wherever I checked
 in the past few days.
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Fri, 8 Oct 2010 11:44:57 +0000
>
>
> For the record:
> Still, no luck. Replacing MxConfig.ms from 4.3 seems to let it get further.
> Or maybe it was M*.
> Problem seems to be that when M3File__IsReadable returns, $l7 gets zeroed.
>
> But I'm going to try another hack.
>
> - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > Date: Thu, 7 Oct 2010 11:22:28 +0000
> >
> >
> > oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.
> >
> > - Jay
> >
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > > Date: Thu, 7 Oct 2010 09:45:49 +0000
> > >
> > >
> > > Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> > > I suspect we are underusing volatile.
> > > e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
> > > The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
> > >
> > > I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> > > all MODIFY_EXPR. There is probably redundancy here.
> > >
> > > Notice that even the original volatization was incomplete.
> > > It volatized current function's current temporaries/locals, but not others declared after
> > > any call to setjmp. I fixed that at some point.
> > >
> > > - Jay
> > >
> > > ----------------------------------------
> > > > From: jay.krell at cornell.edu
> > > > To: m3devel at elegosoft.com
> > > > Subject: random notes: gcc 4.5, sparc, etc.
> > > > Date: Wed, 6 Oct 2010 13:30:00 +0000
> > > >
> > > >
> > > > some random notes
> > > >
> > > > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > > > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > > > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> > > >
> > > > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > > > Same easy test, but it crashes upon first attempt to raise an exception.
> > > >
> > > > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > > > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> > > >
> > > > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > > > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> > > >
> > > > Meanwhile I think many other targets are working ok with 4.5.
> > > > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> > > >
> > > > - Jay
> > > >
> > >
> >
> 		 	   		  

From jay.krell at cornell.edu  Wed Oct 13 11:48:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 13 Oct 2010 09:48:44 +0000
Subject: [M3devel] stack walker vs. gcc 4.5
Message-ID: <COL101-W4428AF300D518BD4AA4D5FE6550@phx.gbl>


I'm really really really really really really inclined to ditch using the one stack walker we use: SOLgnu/SOLsun/SPARC32_SOLARIS.
?I have been trying for quite a while to get it to work with the gcc 4.5 backend with no luck.


We could/should use the gcc exception handling support, thereby getting stack walking for most/all platforms.


Though odds are probably higher of generating C++ source and using exception handling there, and again, getting stack walking.
? (Or C on VMS/NT/OSF1 since they all have exception handling in C; NT/x86 doesn't really do stack walking, but
an optimized form of our non-stackwalking implementation)


?- Jay

 		 	   		  

From hosking at cs.purdue.edu  Wed Oct 13 16:56:34 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 13 Oct 2010 10:56:34 -0400
Subject: [M3devel] stack walker vs. gcc 4.5
In-Reply-To: <COL101-W4428AF300D518BD4AA4D5FE6550@phx.gbl>
References: <COL101-W4428AF300D518BD4AA4D5FE6550@phx.gbl>
Message-ID: <F0708FBD-7C63-48CB-97BF-DE321B69EDBC@cs.purdue.edu>

Yes, agreed we should use gcc exception handling support.  It should not be that hard to use their stack walker.

On 13 Oct 2010, at 05:48, Jay K wrote:

> 
> I'm really really really really really really inclined to ditch using the one stack walker we use: SOLgnu/SOLsun/SPARC32_SOLARIS.
>  I have been trying for quite a while to get it to work with the gcc 4.5 backend with no luck.
> 
> 
> We could/should use the gcc exception handling support, thereby getting stack walking for most/all platforms.
> 
> 
> Though odds are probably higher of generating C++ source and using exception handling there, and again, getting stack walking.
>   (Or C on VMS/NT/OSF1 since they all have exception handling in C; NT/x86 doesn't really do stack walking, but
> an optimized form of our non-stackwalking implementation)
> 
> 
>  - Jay
> 
> 		 	   		  



From dabenavidesd at yahoo.es  Wed Oct 13 21:34:13 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Wed, 13 Oct 2010 20:34:13 +0100 (BST)
Subject: [M3devel] stack walker vs. gcc 4.5
In-Reply-To: <F0708FBD-7C63-48CB-97BF-DE321B69EDBC@cs.purdue.edu>
Message-ID: <79057.93087.qm@web29710.mail.ird.yahoo.com>

Hi all:
I was wondering what is about the Ultrix 4.3 bsd based stack walker and backend for the dec mips based ds3100. Should be a good thing to have some sort of restoration project team in that. Besides that, Utltrix source is publicly available now.
Just in case let me know who knows if anybody wants to look at it.
Thanks in advance 

--- El mi?, 13/10/10, Tony Hosking <hosking at cs.purdue.edu> escribi?:

> De: Tony Hosking <hosking at cs.purdue.edu>
> Asunto: Re: [M3devel] stack walker vs. gcc 4.5
> Para: "Jay K" <jay.krell at cornell.edu>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: mi?rcoles, 13 de octubre, 2010 09:56
> Yes, agreed we should use gcc
> exception handling support.  It should not be that hard
> to use their stack walker.
> 
> On 13 Oct 2010, at 05:48, Jay K wrote:
> 
> > 
> > I'm really really really really really really inclined
> to ditch using the one stack walker we use:
> SOLgnu/SOLsun/SPARC32_SOLARIS.
> >  I have been trying for quite a while to get it
> to work with the gcc 4.5 backend with no luck.
> > 
> > 
> > We could/should use the gcc exception handling
> support, thereby getting stack walking for most/all
> platforms.
> > 
> > 
> > Though odds are probably higher of generating C++
> source and using exception handling there, and again,
> getting stack walking.
> >   (Or C on VMS/NT/OSF1 since they all
> have exception handling in C; NT/x86 doesn't really do stack
> walking, but
> > an optimized form of our non-stackwalking
> implementation)
> > 
> > 
> >  - Jay
> > 
> >    
>         
>           
>   
> 
> 


      


From jay.krell at cornell.edu  Thu Oct 14 05:56:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Oct 2010 03:56:18 +0000
Subject: [M3devel] my hudson nodes
Message-ID: <COL101-W3160FCBFC0EC1688099F33E6560@phx.gbl>


Nearly all of my Hudson nodes are down for now.
Maybe indefinitely.
Or will bring back only x86/AMD64 as VMs.
?(no Linux/sparc, Linux/powerpc, Solaris/sparc, but
we have Solaris/sparc otherwise, the rest are minor,
and others might rehost them at some point, or
I might)


?- Jay
 		 	   		  

From wagner at elegosoft.com  Thu Oct 14 09:56:17 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Oct 2010 09:56:17 +0200
Subject: [M3devel] my hudson nodes
Message-ID: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Nearly all of my Hudson nodes are down for now.
> Maybe indefinitely.
> Or will bring back only x86/AMD64 as VMs.
> ?(no Linux/sparc, Linux/powerpc, Solaris/sparc, but
> we have Solaris/sparc otherwise, the rest are minor,
> and others might rehost them at some point, or
> I might)

Hi Jay,

I feared as much when you offered all your hardware some time ago.
I didn't contact you then because I don't think it would make sense to
ship some of the machines to our offices in Europe (too expensive).

I think especially the xdarwin and xlinux nodes are still of interest
for M3 users. Perhaps somebody else can host those platforms?

Anyway, thank you very much for providing those build and test machines
for the recent years. I hope you just clear up the hardware zoo at your
home and don't plan to give up the work on M3 in general.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney_bates at lcwb.coop  Thu Oct 14 17:05:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 14 Oct 2010 10:05:46 -0500
Subject: [M3devel] my hudson nodes
In-Reply-To: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>
References: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>
Message-ID: <4CB71C4A.2050904@lcwb.coop>



Olaf Wagner wrote:
> Quoting Jay K <jay.krell at cornell.edu>:
> 
>> Nearly all of my Hudson nodes are down for now.
>> Maybe indefinitely.
>> Or will bring back only x86/AMD64 as VMs.
>>  (no Linux/sparc, Linux/powerpc, Solaris/sparc, but
>> we have Solaris/sparc otherwise, the rest are minor,
>> and others might rehost them at some point, or
>> I might)
> 
> Hi Jay,
> 
> I feared as much when you offered all your hardware some time ago.
> I didn't contact you then because I don't think it would make sense to
> ship some of the machines to our offices in Europe (too expensive).
> 
> I think especially the xdarwin and xlinux nodes are still of interest
> for M3 users. Perhaps somebody else can host those platforms?

If/when I manage to get a better internet connection, I could host a few.
Right now, I'm stuck with a satellite connection which, aside from being
somewhat slow on bit rate and absolutely glacial on latency, has draconian
bit quotas, both up and down.  And they slow it down a whole lot more if I
exceed them.  It's the only drawback to living out in tallgrass prairie,
which is in all other respects, wonderful.  I continue to work on
alternatives.

> 
> Anyway, thank you very much for providing those build and test machines
> for the recent years. I hope you just clear up the hardware zoo at your
> home and don't plan to give up the work on M3 in general.
> 
> Olaf


From jay.krell at cornell.edu  Thu Oct 14 23:24:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 14 Oct 2010 21:24:14 +0000
Subject: [M3devel] my hudson nodes
In-Reply-To: <4CB71C4A.2050904@lcwb.coop>
References: <20101014095617.dcupmbf7k0g4gwwo@mail.elegosoft.com>,
	<4CB71C4A.2050904@lcwb.coop>
Message-ID: <COL101-W292F0316E8E53E567884DFE6560@phx.gbl>


xdarwin is a laptop I use regularly. It will stay. It isn't always on.
xlinux is also a laptop and is among first in line to come back or be replaced with a VM on xdarwin.
The vast majority of my hardware has never been Hudson nodes.
But yes it is related.

?- Jay


----------------------------------------
> Date: Thu, 14 Oct 2010 10:05:46 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] my hudson nodes
>
>
>
> Olaf Wagner wrote:
> > Quoting Jay K :
> >
> >> Nearly all of my Hudson nodes are down for now.
> >> Maybe indefinitely.
> >> Or will bring back only x86/AMD64 as VMs.
> >> (no Linux/sparc, Linux/powerpc, Solaris/sparc, but
> >> we have Solaris/sparc otherwise, the rest are minor,
> >> and others might rehost them at some point, or
> >> I might)
> >
> > Hi Jay,
> >
> > I feared as much when you offered all your hardware some time ago.
> > I didn't contact you then because I don't think it would make sense to
> > ship some of the machines to our offices in Europe (too expensive).
> >
> > I think especially the xdarwin and xlinux nodes are still of interest
> > for M3 users. Perhaps somebody else can host those platforms?
>
> If/when I manage to get a better internet connection, I could host a few.
> Right now, I'm stuck with a satellite connection which, aside from being
> somewhat slow on bit rate and absolutely glacial on latency, has draconian
> bit quotas, both up and down. And they slow it down a whole lot more if I
> exceed them. It's the only drawback to living out in tallgrass prairie,
> which is in all other respects, wonderful. I continue to work on
> alternatives.
>
> >
> > Anyway, thank you very much for providing those build and test machines
> > for the recent years. I hope you just clear up the hardware zoo at your
> > home and don't plan to give up the work on M3 in general.
> >
> > Olaf
 		 	   		  

From michael.anderson at elego.de  Fri Oct 15 12:05:18 2010
From: michael.anderson at elego.de (Michael Anderson)
Date: Fri, 15 Oct 2010 12:05:18 +0200
Subject: [M3devel] [elego Server Maintenance] Friday 15.10.2010 20:00
Message-ID: <20101015120518.8q3kbjqmo88kkwoo@mail.elegosoft.com>

Hello,

On Friday, October 15 at 8 PM CEST, we will perform scheduled
maintenance on our servers.
Brief interruptions of service may occur.
Expected duration: 120 Min.

We apologize for any inconvenience.

- the elego Admins


-- 
Michael Anderson
IT Services & Support

elego Software Solutions GmbH
Gustav-Meyer-Allee 25
Building 12.3 (BIG) room 227
13355 Berlin, Germany

phone +49 30 23 45 86 96      michael.anderson at elegosoft.com
fax   +49 30 23 45 86 95      http://www.elegosoft.com

Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin
Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194




From jay.krell at cornell.edu  Sat Oct 16 14:18:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 16 Oct 2010 12:18:53 +0000
Subject: [M3devel] bootstrapping wrinkle,
 incrementality bug when toggling build_standalone
Message-ID: <COL101-W11D13E1A83111DB860A770E6580@phx.gbl>


I found a new bootstrapping wrinkle tonight.
Based on that we typically have pairs of libraries:
NT: foo.lib, foo.lib.sa
Posix: libfoo.a, libfoo.a.sa?
 
 
If there is incompatibility introduced in m3core,
such as I introduced just now for set_member/set_singleton,
it *seems* you can get into a situation where only
one of the two libraries is updated.
 
 
Perhaps because I was hacking shared = false, perhaps
to workaround other problems.
 
 
Anyway, the general technique might be useful.
 ==> move foo.lib.sa to foo.lib
 
 
More generally there IS an obvious problem in the system.
IF I have a library that was previously not standalone,
therefore having both foo.lib and foo.lib.sa,
 
 
and then I change it to always be standalone,
therefore only having foo.lib,
 
 
and then I link a standalone application to it,
the out of date foo.lib.sa will be found and used.
 
 
Solutions include:
 - when shipping, delete related neighboring files.
   i.e. when shipping a non-standalone library, delete the shipped foo.lib.sa.
 - or, always make foo.lib and foo.lib.sa, just that
   they might be identical.
 - or, lame...probe contents not name? if foo.lib appears to be
   standalone, don't probe for foo.lib.sa? Not difficult on NT...
 
 
(This goes to show something I can never very well explain why:
file existance checks, probes, generally indicate problems.)
 
 
 - Jay
  		 	   		  

From jay.krell at cornell.edu  Sun Oct 17 02:27:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 17 Oct 2010 00:27:11 +0000
Subject: [M3devel] firming up atomics?
Message-ID: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>


Tony,

Can we firm up the atomic semantics/implementatino?

Now might be a good time for me to make the NT/x86 backend
definitely work, test it, and make it more efficient.
? (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
?
?
Like, old value vs. new value returned?


Off the cuff, I'd say, better to always return old value.
The new value can always be computed from it.

However we are the mercy of the processors.


And it only matters for or/and.
xor/add/sub/inc/dec can all compute either from either.


Also, please, I don't find the specifications clear.
At least the last time I studied them.


To me they should say, things like,
?"returns the old value" 
?or "returns the new value" 

?
or returns true if compare matched
or returns false if the compare matched
etc.


The mentions of "spurious failure" or whatnot didn't make sense either.
They should say, something like:
returns true if the compare matched
?but sometimes even if the compare should have matched,
?it won't, and false will be returned -- specify everything that happens when there is "failure".

?
Furthermore, if you look at what Microsoft compilers provide,
they provide a bunch of very simple very clear well documented functions,
that the compiler implements and inlines.
?(at least if you ignore the qcuire/release stuff that confuses me...


You could specify in terms of them.
?Really. A good idea.


ie: is our compare_exchange equivalent to InterlockedCompareExchange?
? Or maybe parameter order different?

? 
Of course, I understand, the types supported by the Microsoft
intrinsics have varied through time and slowly grown.
8bit and 16bit might still be lacking but 32bit and 64bit are very
complete. 64bit atomic operations on 32bit x86 processors 
since Pentium or so can be synthesized with a loop over
InterlockedCompareExchange64.


Or in terms of the gcc intrinsics, probably similarly ok.


We should probably also nail down the implementation where
they aren't available.


And maybe put in safer defaults?
? And quickly improve where we can, e.g. on all x86/AMD64 platforms.
? 

?Thanks,
?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Sun Oct 17 14:48:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 17 Oct 2010 08:48:09 -0400
Subject: [M3devel] firming up atomics?
In-Reply-To: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>
References: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>
Message-ID: <FF060A4B-7136-4FA7-89BB-712B96FC710B@cs.purdue.edu>

I still have some fixes to check in before turning it on again.
They are intended to match the approved C++0x standard.

On 16 Oct 2010, at 20:27, Jay K wrote:

> 
> Tony,
> 
> Can we firm up the atomic semantics/implementatino?
> 
> Now might be a good time for me to make the NT/x86 backend
> definitely work, test it, and make it more efficient.
>   (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
>  
>  
> Like, old value vs. new value returned?
> 
> 
> Off the cuff, I'd say, better to always return old value.
> The new value can always be computed from it.
> 
> However we are the mercy of the processors.
> 
> 
> And it only matters for or/and.
> xor/add/sub/inc/dec can all compute either from either.
> 
> 
> Also, please, I don't find the specifications clear.
> At least the last time I studied them.
> 
> 
> To me they should say, things like,
>  "returns the old value" 
>  or "returns the new value" 
> 
>  
> or returns true if compare matched
> or returns false if the compare matched
> etc.
> 
> 
> The mentions of "spurious failure" or whatnot didn't make sense either.
> They should say, something like:
> returns true if the compare matched
>  but sometimes even if the compare should have matched,
>  it won't, and false will be returned -- specify everything that happens when there is "failure".
> 
>  
> Furthermore, if you look at what Microsoft compilers provide,
> they provide a bunch of very simple very clear well documented functions,
> that the compiler implements and inlines.
>  (at least if you ignore the qcuire/release stuff that confuses me...
> 
> 
> You could specify in terms of them.
>  Really. A good idea.
> 
> 
> ie: is our compare_exchange equivalent to InterlockedCompareExchange?
>   Or maybe parameter order different?
> 
>   
> Of course, I understand, the types supported by the Microsoft
> intrinsics have varied through time and slowly grown.
> 8bit and 16bit might still be lacking but 32bit and 64bit are very
> complete. 64bit atomic operations on 32bit x86 processors 
> since Pentium or so can be synthesized with a loop over
> InterlockedCompareExchange64.
> 
> 
> Or in terms of the gcc intrinsics, probably similarly ok.
> 
> 
> We should probably also nail down the implementation where
> they aren't available.
> 
> 
> And maybe put in safer defaults?
>   And quickly improve where we can, e.g. on all x86/AMD64 platforms.
>   
> 
>  Thanks,
>  - Jay
> 		 	   		  



From ttmrichter at gmail.com  Mon Oct 18 19:08:07 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Tue, 19 Oct 2010 01:08:07 +0800
Subject: [M3devel] CM3, Windows and GCC
Message-ID: <AANLkTikK=HwxCsGtpHSe__KzNWOzjg54a0v8pwocU=WM@mail.gmail.com>

Is there any way through, say, MinGW (or, if absolutely necessary, Cygwin)
to get the back-end for CM3 to target GCC on Windows instead of Microsoft's
tool chain?

-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101019/c425ee8e/attachment-0002.html>

From jay.krell at cornell.edu  Tue Oct 19 08:48:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 19 Oct 2010 06:48:32 +0000
Subject: [M3devel] firming up atomics?
In-Reply-To: <FF060A4B-7136-4FA7-89BB-712B96FC710B@cs.purdue.edu>
References: <COL101-w6592FE51644511EE6AFB9AE6590@phx.gbl>,
	<FF060A4B-7136-4FA7-89BB-712B96FC710B@cs.purdue.edu>
Message-ID: <COL101-W40DE4DFA20016824C36938E65B0@phx.gbl>


Tony, hm, the full generality, in the backend, I think it should be a parameter whether or not the old value or new value or both or neither are returned.
 
See how the Microsoft intrinsics return the old value, but the x86 instructions return the new value, necessitating compare/exchange loops, unless the value is ignored, in which case much more efficient:
 
"v" for void:
 
void __fastcall vor(long a, long b) { _InterlockedOr(a, b); }
long __fastcall or(long a, long b) { return _InterlockedOr(a, b); }
 
void __fastcall vxor(long a, long b) { _InterlockedXor(a, b); }
long __fastcall xor(long a, long b) { return _InterlockedXor(a, b); }
 
void __fastcall vand(long a, long b) { _InterlockedAnd(a, b); }
long __fastcall and(long a, long b) { return _InterlockedAnd(a, b); }

 
C:\>cl -c 1.c -FAsc -Ox && more 1.cod

; 3    : void __fastcall vor(long a, long b) { _InterlockedOr(a, b); }
  00000 f0 09 11         lock     or     DWORD PTR [ecx], edx
  00003 c3               ret     0

; 4    : long __fastcall or(long a, long b) { return _InterlockedOr(a, b); }
  00010 56               push    esi
  00011 8b 01            mov     eax, DWORD PTR [ecx]
$LN3@:
  00013 8b f0            mov     esi, eax
  00015 0b f2            or      esi, edx
  00017 f0 0f b1 31      lock     cmpxchg DWORD PTR [ecx], esi
  0001b 75 f6            jne     SHORT $LN3@
  0001d 5e               pop     esi
  0001e c3               ret     0

 
; 6    : void __fastcall vxor(long a, long b) { _InterlockedXor(a, b); }
  00020 f0 31 11         lock     xor    DWORD PTR [ecx], edx
  00023 c3               ret     0

 
; 7    : long __fastcall xor(long a, long b) { return _InterlockedXor(a, b); }
  00030 56               push    esi
  00031 8b 01            mov     eax, DWORD PTR [ecx]
$LN3@:
  00033 8b f0            mov     esi, eax
  00035 33 f2            xor     esi, edx
  00037 f0 0f b1 31      lock     cmpxchg DWORD PTR [ecx], esi
  0003b 75 f6            jne     SHORT $LN3@
  0003d 5e               pop     esi
  0003e c3               ret     0

 
; 9    : void __fastcall vand(long a, long b) { _InterlockedAnd(a, b); }
  00040 f0 21 11         lock     and    DWORD PTR [ecx], edx
  00043 c3               ret     0

 
; 10   : long __fastcall and(long a, long b) { return _InterlockedAnd(a, b); }
  00050 56               push    esi
  00051 8b 01            mov     eax, DWORD PTR [ecx]
$LN3@:
  00053 8b f0            mov     esi, eax
  00055 23 f2            and     esi, edx
  00057 f0 0f b1 31      lock     cmpxchg DWORD PTR [ecx], esi
  0005b 75 f6            jne     SHORT $LN3@
  0005d 5e               pop     esi
  0005e c3               ret     0
@and at 8  ENDP
_TEXT   ENDS
END
 
 
 - Jay


 
> Subject: Re: [M3devel] firming up atomics?
> From: hosking at cs.purdue.edu
> Date: Sun, 17 Oct 2010 08:48:09 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> I still have some fixes to check in before turning it on again.
> They are intended to match the approved C++0x standard.
> 
> On 16 Oct 2010, at 20:27, Jay K wrote:
> 
> > 
> > Tony,
> > 
> > Can we firm up the atomic semantics/implementatino?
> > 
> > Now might be a good time for me to make the NT/x86 backend
> > definitely work, test it, and make it more efficient.
> > (ie. not using InterlockedCompareExchange loop for InterlockedIncrement when a simple xadd will work).
> > 
> > 
> > Like, old value vs. new value returned?
> > 
> > 
> > Off the cuff, I'd say, better to always return old value.
> > The new value can always be computed from it.
> > 
> > However we are the mercy of the processors.
> > 
> > 
> > And it only matters for or/and.
> > xor/add/sub/inc/dec can all compute either from either.
> > 
> > 
> > Also, please, I don't find the specifications clear.
> > At least the last time I studied them.
> > 
> > 
> > To me they should say, things like,
> > "returns the old value" 
> > or "returns the new value" 
> > 
> > 
> > or returns true if compare matched
> > or returns false if the compare matched
> > etc.
> > 
> > 
> > The mentions of "spurious failure" or whatnot didn't make sense either.
> > They should say, something like:
> > returns true if the compare matched
> > but sometimes even if the compare should have matched,
> > it won't, and false will be returned -- specify everything that happens when there is "failure".
> > 
> > 
> > Furthermore, if you look at what Microsoft compilers provide,
> > they provide a bunch of very simple very clear well documented functions,
> > that the compiler implements and inlines.
> > (at least if you ignore the qcuire/release stuff that confuses me...
> > 
> > 
> > You could specify in terms of them.
> > Really. A good idea.
> > 
> > 
> > ie: is our compare_exchange equivalent to InterlockedCompareExchange?
> > Or maybe parameter order different?
> > 
> > 
> > Of course, I understand, the types supported by the Microsoft
> > intrinsics have varied through time and slowly grown.
> > 8bit and 16bit might still be lacking but 32bit and 64bit are very
> > complete. 64bit atomic operations on 32bit x86 processors 
> > since Pentium or so can be synthesized with a loop over
> > InterlockedCompareExchange64.
> > 
> > 
> > Or in terms of the gcc intrinsics, probably similarly ok.
> > 
> > 
> > We should probably also nail down the implementation where
> > they aren't available.
> > 
> > 
> > And maybe put in safer defaults?
> > And quickly improve where we can, e.g. on all x86/AMD64 platforms.
> > 
> > 
> > Thanks,
> > - Jay
> > 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101019/d4c27182/attachment-0002.html>

From jay.krell at cornell.edu  Tue Oct 19 12:39:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 19 Oct 2010 10:39:35 +0000
Subject: [M3devel] CM3, Windows and GCC
In-Reply-To: <AANLkTikK=HwxCsGtpHSe__KzNWOzjg54a0v8pwocU=WM@mail.gmail.com>
References: <AANLkTikK=HwxCsGtpHSe__KzNWOzjg54a0v8pwocU=WM@mail.gmail.com>
Message-ID: <COL101-W761547F7BEDE16B44EB9DE65B0@phx.gbl>


Yes, both such targets exist, I386_CYGWIN and I386_MINGW.
Nobody uses them. But they are there and have worked in the past.
Maybe time to make sure they work and keep them working (Hudson).
 
 
However you have somewhat confused apples/oranges.
Somewhat. We have our own builtin code generator. We only use
Microsoft tools for 1) a little bit of C 2) linker 3) C runtime.
You ought to be able to combine either backend with either runtime and either C compiler and either linker. Though I noticed the C runtimes are somewhat tied to the linkers.
 
Note that our builtin code generator generates pretty good code and does it fast.
 
MinGW is probably the way to go for "AMD64_NT" though.
  Or the proverbial C backend.
 
 
 - Jay


________________________________
> Date: Tue, 19 Oct 2010 01:08:07 +0800
> From: ttmrichter at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] CM3, Windows and GCC
>
> Is there any way through, say, MinGW (or, if absolutely necessary,
> Cygwin) to get the back-end for CM3 to target GCC on Windows instead of
> Microsoft's tool chain?
>
> -- 		 	   		  

From jay.krell at cornell.edu  Sat Oct 23 12:06:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 23 Oct 2010 10:06:39 +0000
Subject: [M3devel] typenames vs. lexical scope vs. backend?
Message-ID: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>


Um.. the same name can be different types, in different scopes.


<*NOWARN*>PROCEDURE F1() =
TYPE T1 = INTEGER;
BEGIN
END F1;

<*NOWARN*>PROCEDURE F2() =
TYPE T1 = LONGINT;
BEGIN
END F2;

=>

(16) declare_procedure name:Main__F1 n_params:0 return_type:void lev:0 exported:false
(17) declare_typename my_id:0x195C2A74 name:T1

(18) declare_procedure name:Main__F2 n_params:0 return_type:void lev:0 exported:false
(19) declare_typename my_id:0x5562176 name:T1
(20) comment comment:F1
(21) set_source_line 6

(22) begin_procedure procedure:Main__F1
(23)???? set_source_line 7
(24)???? set_source_line 9
(25)???? exit_proc type:void
(26) end_procedure procedure:Main__F1

(27) comment comment:F2
(28) set_source_line 0xB(11)
(29) begin_procedure procedure:Main__F2
(30)???? set_source_line 0xC(12)
(31)???? set_source_line 0xE(14)
(32)???? exit_proc type:void
(33) end_procedure procedure:Main__F2


Is the backend to record the types within some scope, and then observe
the scopes coming back?


Or, then again, are typenames worth much to the backend?
Well, maybe.
They aren't needed for display the values of variables,
but they might be nice in expressions that include casts?

I'm thinking maybe the right thing is to ignore them in the backend.
??

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Sat Oct 23 20:04:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 23 Oct 2010 14:04:12 -0400
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
Message-ID: <E2C44EC5-93F6-4063-9224-316DDA91100E@cs.purdue.edu>

You could mangle the name to prefix the scope.

On 23 Oct 2010, at 06:06, Jay K wrote:

> 
> Um.. the same name can be different types, in different scopes.
> 
> 
> <*NOWARN*>PROCEDURE F1() =
> TYPE T1 = INTEGER;
> BEGIN
> END F1;
> 
> <*NOWARN*>PROCEDURE F2() =
> TYPE T1 = LONGINT;
> BEGIN
> END F2;
> 
> =>
> 
> (16) declare_procedure name:Main__F1 n_params:0 return_type:void lev:0 exported:false
> (17) declare_typename my_id:0x195C2A74 name:T1
> 
> (18) declare_procedure name:Main__F2 n_params:0 return_type:void lev:0 exported:false
> (19) declare_typename my_id:0x5562176 name:T1
> (20) comment comment:F1
> (21) set_source_line 6
> 
> (22) begin_procedure procedure:Main__F1
> (23)     set_source_line 7
> (24)     set_source_line 9
> (25)     exit_proc type:void
> (26) end_procedure procedure:Main__F1
> 
> (27) comment comment:F2
> (28) set_source_line 0xB(11)
> (29) begin_procedure procedure:Main__F2
> (30)     set_source_line 0xC(12)
> (31)     set_source_line 0xE(14)
> (32)     exit_proc type:void
> (33) end_procedure procedure:Main__F2
> 
> 
> Is the backend to record the types within some scope, and then observe
> the scopes coming back?
> 
> 
> Or, then again, are typenames worth much to the backend?
> Well, maybe.
> They aren't needed for display the values of variables,
> but they might be nice in expressions that include casts?
> 
> I'm thinking maybe the right thing is to ignore them in the backend.
> ??
> 
>  - Jay
> 		 	   		  



From dragisha at m3w.org  Sat Oct 23 21:44:16 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sat, 23 Oct 2010 21:44:16 +0200
Subject: [M3devel] Runtime only package for Windows? With preselected
	modules?
Message-ID: <1287863056.19814.1585.camel@boromir.m3w.org>

I have a rpm spec file I am using and it by default makes cm3 package
and cm3-devel. Also, it does not contain all modula-3 packages, as most
of them are not used in typical cases.

Right now I am about to make install package for an application I am
delivering and runtime libs only package for Windows is what is on my
mind right now. Doable? Or I can skip it without problem with
build_standalone() ? How do I confirm it's statically linked? Under
linux I'll use ldd, but depends.exe (thanks Jay) does not show it to
me...Or it does?
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Sun Oct 24 02:30:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 24 Oct 2010 00:30:52 +0000
Subject: [M3devel] Runtime only package for Windows? With preselected
 modules?
In-Reply-To: <1287863056.19814.1585.camel@boromir.m3w.org>
References: <1287863056.19814.1585.camel@boromir.m3w.org>
Message-ID: <COL101-W408980139AB55C72705EC0E6400@phx.gbl>


With build_standalone you don't need to worry.
  As long as all your Modula-3 code is in one .dll per process.
  Er, I mean, as long as your Modula-3 is the .exe and no .dlls.


There is some need for shared state sometimes.
But if all the Modula-3 code is linked together, in the .exe, ok.


You know, imagine you have multiple Modula-3 .dlls loaded, standalone.
Which garbage collector? Maybe all of them, against their own allocations.
Maybe it is jus slow.


But what if you pass off Modula-3 traced references across .dll boundaries,
without sharing a garbage collector (m3core.dll). Then you'd have trouble.


This has nothing to do with Windows.
It is the general hazard of dynamic linking.


Sometimes dynamic linking is an opportunistic optimization.
  e.g. it doesn't matter if you share strlen or not. It is stateless. You can have
  any number of copies. More efficient to reduce, but not a big deal these days,
  with tons of disk space and address space and physical memory.


But sometimes a .dll is managing a shared resource.
e.g. some global variables.
Then having multiple copies of data/code can be confusing or very wrong.
e.g. consider something like setlocale().
Which code does it affect? Only code using the same C runtime.


Imagine I call fopen or malloc and give the result to another .dll that
calls fread or free. They have to share the same C runtime.
Or in a less likely case, the multiple C runtimes have to cooperate.


Same problem with CreateFile/ReadFile/CloseHandle, except
the system doesn't allow duplicate kernel32.dll or the underlying ntoskrnl.exe.


Think of "services".
For example there is "BITS" the background intelligent transfer service..
used by Windows Update. If you have more than one on a machine,
then the "background" and "intelligent" suffer.
But it'd still mostly work?


 - Jay

> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Sat, 23 Oct 2010 21:44:16 +0200
> Subject: [M3devel] Runtime only package for Windows? With preselected	modules?
> 
> I have a rpm spec file I am using and it by default makes cm3 package
> and cm3-devel. Also, it does not contain all modula-3 packages, as most
> of them are not used in typical cases.
> 
> Right now I am about to make install package for an application I am
> delivering and runtime libs only package for Windows is what is on my
> mind right now. Doable? Or I can skip it without problem with
> build_standalone() ? How do I confirm it's statically linked? Under
> linux I'll use ldd, but depends.exe (thanks Jay) does not show it to
> me...Or it does?
> -- 
> Dragi?a Duri? <dragisha at m3w.org>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101024/56e18a25/attachment-0002.html>

From rodney_bates at lcwb.coop  Sun Oct 24 02:50:04 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 23 Oct 2010 19:50:04 -0500
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>
Message-ID: <4CC382BC.2080509@lcwb.coop>

No different from names of variables, formals, constants, or procedures.
I can't think why the backend would need them for code generation/optimization.

They do belong in debug info, however.  This happens now for type names in
stabs+ debug output, although the encoding is a mess, and quite different
from variables, etc.  m3gdb recognizes them in debug commands and applies
the usual scope rules in doing so.  They can be used, e.g. in LOOPHOLE.
In a few cases, m3gdb will give you a bit of structural description of
a type, but often just fully qualifies the type name and repeats that.
When there are multiple names for the same (structurally) type, it is you may
get a synonym type name.

I suspect there is some internal backend tracing that would also benefit from
type names, as with variables, etc.


Jay K wrote:
> Um.. the same name can be different types, in different scopes.
> 
> 
> <*NOWARN*>PROCEDURE F1() =
> TYPE T1 = INTEGER;
> BEGIN
> END F1;
> 
> <*NOWARN*>PROCEDURE F2() =
> TYPE T1 = LONGINT;
> BEGIN
> END F2;
> 
> =>
> 
> (16) declare_procedure name:Main__F1 n_params:0 return_type:void lev:0 exported:false
> (17) declare_typename my_id:0x195C2A74 name:T1
> 
> (18) declare_procedure name:Main__F2 n_params:0 return_type:void lev:0 exported:false
> (19) declare_typename my_id:0x5562176 name:T1
> (20) comment comment:F1
> (21) set_source_line 6
> 
> (22) begin_procedure procedure:Main__F1
> (23)     set_source_line 7
> (24)     set_source_line 9
> (25)     exit_proc type:void
> (26) end_procedure procedure:Main__F1
> 
> (27) comment comment:F2
> (28) set_source_line 0xB(11)
> (29) begin_procedure procedure:Main__F2
> (30)     set_source_line 0xC(12)
> (31)     set_source_line 0xE(14)
> (32)     exit_proc type:void
> (33) end_procedure procedure:Main__F2
> 
> 
> Is the backend to record the types within some scope, and then observe
> the scopes coming back?
> 
> 
> Or, then again, are typenames worth much to the backend?
> Well, maybe.
> They aren't needed for display the values of variables,
> but they might be nice in expressions that include casts?
> 
> I'm thinking maybe the right thing is to ignore them in the backend.
> ??
> 
>  - Jay
>  		 	   		  


From dragisha at m3w.org  Sun Oct 24 07:59:51 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 24 Oct 2010 07:59:51 +0200
Subject: [M3devel] Runtime only package for Windows? With preselected
 modules?
In-Reply-To: <COL101-W408980139AB55C72705EC0E6400@phx.gbl>
References: <1287863056.19814.1585.camel@boromir.m3w.org>
	<COL101-W408980139AB55C72705EC0E6400@phx.gbl>
Message-ID: <1287899991.19814.1680.camel@boromir.m3w.org>

Thank you for elaborate answer.

I did build_standalone() and so far so good... It only pulls system libs
as .dlls (and it is clearly visible by depends.exe) and C libs I
linked. 

Under Linux I changed link command so it linked part of these libs
statically too... I think we need more control there (previously
discussed import_static()). C people have that curse|control point where
they have to specify their link commands, but we probably need to
recognize patterns so we can abstract in m3makefiles and pass them on to
lower levels.

I do not agree on "big physical memory and everything..". No matter how
spacious modern computers are, bad design can chew all that in no time.
Same is true for processor speeds and we all recognize that, but we
easily forget about space being other leg of software/algorightm
efficiency.

On Sun, 2010-10-24 at 00:30 +0000, Jay K wrote:
> With build_standalone you don't need to worry.
>   As long as all your Modula-3 code is in one .dll per process.
>   Er, I mean, as long as your Modula-3 is the .exe and no .dlls.
> 
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Mon Oct 25 02:15:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 25 Oct 2010 00:15:46 +0000
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <4CC382BC.2080509@lcwb.coop>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>,
	<4CC382BC.2080509@lcwb.coop>
Message-ID: <COL101-W48B2A9FB06B01EA23B2E4DE6410@phx.gbl>


> No different from names of variables, formals, constants, or procedures.
> I can't think why the backend would need them for code generation/optimization.

 
For debugging.
 

> They do belong in debug info, however.
 
 
Exactly. Maybe.
Except, I'm thinking..maybe only for entering expressions with casts?
Maybe not for viewing any values?
 
I think the way the compiler is currently structured, it is a lot of work to get this right,
and not with much gain.
The gain would be that typenames in expressions with casts would be 1) evaluated
relative to context 2) easier...typenames should probably be lengthened
in order to have a context-independent name. The lexical scopes
that introduce type names, in order of decreasing frequency would be roughly:
  module
  toplevel function in a module
  block or nested function 
 
We could qualify typenames with Module or Module.Function or Module.Function.NestedFunction.
There's no obvious good name for blocks (WITH, FOR, etc.), but maybe numbers 0, 1, 2, etc.
 
 
I think the frontend and frontend/backend interface need work.
In this case there's not much to gain.
I'll cover something else in a separate mail.
 
 
 - Jay
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101025/675b348f/attachment-0002.html>

From jay.krell at cornell.edu  Mon Oct 25 02:21:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 25 Oct 2010 00:21:43 +0000
Subject: [M3devel] backend and field/array references
Message-ID: <COL101-W293BBD4A33BC418CA80B56E6410@phx.gbl>


The frontend/backend interface should have notions of record field accesses and array indexing.
I'm not sure exactly what they should look like but it shouldn't be difficult to figure out,
at least some simple approaches that scale well enough, even if not ideally.
 
 
For example, every field in a record should either have an id 0, 1, 2, etc. allocated within the record.
OR every field in a record should have an id a la hashes/fingerprints, that could be
sorted/searched globally, even if that isn't as efficient as it could be.
 
 
What I'll probably get working before any of this is in m3_load/store, do a linear search within
the fields of the variable for a field whose offset/size matches.
But linearch search is almost never a good solution.
It could be implemented as binary search with the current interface.
 
 
Due to the danger of layout mismatch, I'm plenty willing for field/array accesses to include
with them the offset the frontend believes them to be at, and it'd be a checked internal error
in the backend if the frontend and backend offset/size disagree.
This would also aid backends that don't have such a high level internal representation (i.e.: NT386).
 
 
I have something prototyped here and it somewhat works.
I have a check that all accesses can be have a field deduced for them.
The first place that fails is for open arrays, for obvious reasons, which I'll fix.
I'll see how it goes from there.
 
 
Ultimately I'm still keen on a C-generating frontend, which does not moot this.
  It would allow for more sensible C to be generated.
 
 
 
 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101025/cf3720ff/attachment-0002.html>

From rodney_bates at lcwb.coop  Mon Oct 25 19:17:48 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Mon, 25 Oct 2010 12:17:48 -0500
Subject: [M3devel] typenames vs. lexical scope vs. backend?
In-Reply-To: <COL101-W48B2A9FB06B01EA23B2E4DE6410@phx.gbl>
References: <COL101-W3144AF0AEC3035FCD1EA43E65F0@phx.gbl>,
	<4CC382BC.2080509@lcwb.coop>
	<COL101-W48B2A9FB06B01EA23B2E4DE6410@phx.gbl>
Message-ID: <4CC5BBBC.5070206@lcwb.coop>



Jay K wrote:
>  > No different from names of variables, formals, constants, or procedures.
>  > I can't think why the backend would need them for code 
> generation/optimization.
> 
>  
> For debugging.
>  
> 
>  > They do belong in debug info, however.
>  
>  
> Exactly. Maybe.
> Except, I'm thinking..maybe only for entering expressions with casts?
> Maybe not for viewing any values?
>  
> I think the way the compiler is currently structured, it is a lot of 
> work to get this right,
> and not with much gain.
> The gain would be that typenames in expressions with casts would be 1) 
> evaluated
> relative to context 2) easier...typenames should probably be lengthened
> in order to have a context-independent name. The lexical scopes
> that introduce type names, in order of decreasing frequency would be 
> roughly:
>   module
>   toplevel function in a module
>   block or nested function
>  
> We could qualify typenames with Module or Module.Function or 
> Module.Function.NestedFunction.
> There's no obvious good name for blocks (WITH, FOR, etc.), but maybe 
> numbers 0, 1, 2, etc.

Whether it's either obvious or good remains subject to debate, but there is already
a system for this, used by m3gdb.  See doc/help/m3gdb/m3gdb-onepage.html, section
"linespecs that are qualified references".  As for the subterfuge behind the scenes,
wherein the compiler and m3gdb communicate info through stabs+, it's a mess.

>  
>  
> I think the frontend and frontend/backend interface need work.
> In this case there's not much to gain.
> I'll cover something else in a separate mail.
>  
>  
>  - Jay
>  


From jay.krell at cornell.edu  Wed Oct 27 09:24:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 07:24:09 +0000
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
Message-ID: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>


My Linux/x86 and OpenBSD/x86 nodes are back from a few days ago.
?? err..need to check if they are working..

I'm experimenting with using Amazon Web Services though.
Reserved micro instances are about $7/month if I computed correctly and the first is free for the first year.
Unclear how easy OpenBSD/NetBSD etc. are to run there though.
? Or maybe just slow (i.e. not paravirtualized)
I'm seeing stuff in German lately in Hudson, but I understand very little German.
It looks like cvs/gcc is moving?
?Or all of cm3/cvs?


e.g.: http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console

http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console


(implied: others here should probably setup some instances, at least if non-Linux proves easy enough;
I'll try OpenBSD probably first)

?- Jay
 		 	   		  

From wagner at elegosoft.com  Wed Oct 27 10:04:09 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 27 Oct 2010 10:04:09 +0200
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
In-Reply-To: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>
References: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>
Message-ID: <20101027100409.3807ovva8gs80os4@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> My Linux/x86 and OpenBSD/x86 nodes are back from a few days ago.
> ?? err..need to check if they are working..
>
> I'm experimenting with using Amazon Web Services though.
> Reserved micro instances are about $7/month if I computed correctly   
> and the first is free for the first year.
> Unclear how easy OpenBSD/NetBSD etc. are to run there though.
> ? Or maybe just slow (i.e. not paravirtualized)

I haven't tried that yet; but if you want to set up a test node there,
that would be welcome.

> I'm seeing stuff in German lately in Hudson, but I understand very   
> little German.

I've seen that, too, now and then. It's not intended, and likely to be
a configuration issue or a global OS setting that somehow gets
heeded now. Perhaps Mike can shed some light on this if he can spare
some minutes...

> It looks like cvs/gcc is moving?
> ?Or all of cm3/cvs?

I'm not sure what you are hinting at with that.
I don't know of any move, nor have I heard anything new of the git/hg
front work.

> e.g.:   
> http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console
>
> http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console

These are examples of German texts I assume...
We'll try to fix that, but it's low priority.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Wed Oct 27 10:22:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 08:22:55 +0000
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
In-Reply-To: <20101027100409.3807ovva8gs80os4@mail.elegosoft.com>
References: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>,
	<20101027100409.3807ovva8gs80os4@mail.elegosoft.com>
Message-ID: <COL101-W7401FFDF127168A912361E6430@phx.gbl>


> > I'm experimenting with using Amazon Web Services though.
> I haven't tried that yet; but if you want to set up a test node there,
> that would be welcome.


It's gotten further. Below.


> > It looks like cvs/gcc is moving?
> >  Or all of cm3/cvs?
>
> I'm not sure what you are hinting at with that.


Look at the CVS roots in hudson.
I'm seeing cm3cvs.acme-works.com.
I never saw that before tonight.


> > e.g.:
> > http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console
> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console
>
> These are examples of German texts I assume...

That too..
But: These are examples running in Amazon Web Services actually.
"jaws1" -- Jay Amazon Web Services 1


question then: what is the thinking around having multiple nodes of same "type"?
? You know..I setup a "test" node..can that coexist with a "real" node? Or only in that
? I fiddle with the jobs to be on one, run them, and then put it back if it didsn't work?
Shedule the jobs on all of them?
If they all work, purely redundant.
If some nodes down, the redundancy useful?
I could see powering off the AWS nodes for long periods to save money.
? esp. if I get NetBSD and OpenBSD running there.
? heck, it might be possible to run Darwin there. Might.
Just change the "tags" that "bind" jobs to machines, to say like linux-i386 instead of machine names xlinux, jaws1, etc.??


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed Oct 27 10:46:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 08:46:21 +0000
Subject: [M3devel] small problems bring up new node
Message-ID: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>


Olaf, bringing up new nodes I think finds small problems in the automation.


new node: jaws1 which is Linux/x86
? (Rename it if you don't like it.)

? 
initial install worked in one attempt, good:
http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/


building cm3cg worked in one attempt, good:
http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/


but building the rest failed, for lack of "last ok" build:
http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull


I'm sure if I just copy stuff around it'll work.
Unless we need to start with a newer release,
which is a different matter if so.


This node was cloned from xlinux and I just changed the node
name and node to ssh to.


(The great thing about a C backend is all this testing
across every architecture would all but disappear..)


?- Jay 		 	   		  

From wagner at elegosoft.com  Wed Oct 27 11:02:19 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 27 Oct 2010 11:02:19 +0200
Subject: [M3devel] hudson nodes/awazon web services/cvs moving?
In-Reply-To: <COL101-W7401FFDF127168A912361E6430@phx.gbl>
References: <COL101-W24BEB467F72ED0B305FE3BE6430@phx.gbl>,
	<20101027100409.3807ovva8gs80os4@mail.elegosoft.com>
	<COL101-W7401FFDF127168A912361E6430@phx.gbl>
Message-ID: <20101027110219.q48envgsgwwg0k44@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

>> > I'm experimenting with using Amazon Web Services though.
>> I haven't tried that yet; but if you want to set up a test node there,
>> that would be welcome.
>
> It's gotten further. Below.
Ah.

>> > It looks like cvs/gcc is moving?
>> >  Or all of cm3/cvs?
>>
>> I'm not sure what you are hinting at with that.
>
> Look at the CVS roots in hudson.
> I'm seeing cm3cvs.acme-works.com.
> I never saw that before tonight.

Oops, I forgot about that. That's a mirror on a virtual machine
Mike has set up; I thought I posted that to the list. Only a few
jobs use(d) it until now though. It's only a temporary solution,
though these always tend to become long-living :-)

>> > e.g.:
>> >   
>> http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/console
>> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/console
>>
>> These are examples of German texts I assume...
>
> That too..
> But: These are examples running in Amazon Web Services actually.
> "jaws1" -- Jay Amazon Web Services 1
>
> question then: what is the thinking around having multiple nodes of   
> same "type"?

You mean for one target platform, I assume?

> ? You know..I setup a "test" node..can that coexist with a "real"   
> node? Or only in that
> ? I fiddle with the jobs to be on one, run them, and then put it   
> back if it didsn't work?

Feel free to add test nodes as you need (not necessarily run continuous
integration on them because of the load that generates).

> Shedule the jobs on all of them?
We shouldn't actually run the same builds and tests on multiple nodes
for a longer period of time.

> If they all work, purely redundant.
> If some nodes down, the redundancy useful?

Yes, it would be great to have an automated switchover in this case.
Except for the job dependeny from build on m3cc there should be no
problem in defining a group of equivalent nodes in Hudson (that's the
provided concept).

> I could see powering off the AWS nodes for long periods to save money.
> ? esp. if I get NetBSD and OpenBSD running there.
> ? heck, it might be possible to run Darwin there. Might.
> Just change the "tags" that "bind" jobs to machines, to say like   
> linux-i386 instead of machine names xlinux, jaws1, etc.??

Yes, that's the mechanism to define groups of equivalent slave
machines. Add a unique tag to all the build nodes that may run your job
and use that in the job definition.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Wed Oct 27 11:19:49 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 27 Oct 2010 11:19:49 +0200
Subject: [M3devel] small problems bring up new node
In-Reply-To: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>
References: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>
Message-ID: <20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>

Quoting Jay K <jay.krell at cornell.edu>:

> Olaf, bringing up new nodes I think finds small problems in the automation.
>
> new node: jaws1 which is Linux/x86
> ? (Rename it if you don't like it.)
> ?
> initial install worked in one attempt, good:
> http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/
>
> building cm3cg worked in one attempt, good:
> http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/
>
> but building the rest failed, for lack of "last ok" build:
> http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull

That hasn't been realluy automated in a generic fashion yet.
I always had to perform several steps more or less manually due to
different environments etc. If you can write a general boot or init
job that will be great.

The build and test jobs all expect valid cm3 package pool setups
in current and lastok. That at least should be easy to automate.

> I'm sure if I just copy stuff around it'll work.
> Unless we need to start with a newer release,
> which is a different matter if so.
>
> This node was cloned from xlinux and I just changed the node
> name and node to ssh to.

There are different variants of init jobs for different platforms.
Maybe you just were unlucky to pick a rather old one :-/

> (The great thing about a C backend is all this testing
> across every architecture would all but disappear..)

No, it wouldn't. We could neither be sure that the generated C code
compiles with a native compiler (unless we require the same version
of gcc everywhere) nor that it would perform in the same way on all
platforms. That doesn't mean that a C backend wouldn't be a great
extension, of course.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Wed Oct 27 11:28:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 27 Oct 2010 09:28:14 +0000
Subject: [M3devel] small problems bring up new node
In-Reply-To: <20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>
References: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>,
	<20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>
Message-ID: <COL101-W53C69CA2CF01060D50A5EBE6430@phx.gbl>


Hm. I think most of the code is outside of Hudson by now, but I'll poke around.


We would generate highly portable C/C++.
We wouldn't depend on gcc. gcc just isn't, in my experience, so much better/different
than any other C/C++ compiler -- partly because I mostly use Microsoft Visual C++ and
that compiler has fairly few extensions. Perhaps if I used gcc more I'd be lulled into using
its many unique extensions.
#ifdef linux would generally suffice for Linux on all processors.
? No need for the ppc/sparc/etc. machines.
#ifdef freebsd ditto.
? No need for the ppc/sparc/etc. machines.
As well, autoconf might subsume some of that.

We might still try to have some 32bit and 64bit machines, some sparc, mips, etc., but
? no need for the full cross product.


endian and wordsize would be separate factors
We may or may not need to know them statically.
i.e. we would either typedef integer like in m3core.h, or use autoconf.


I think if m3cg had a notion of a field reference, the front end would no longer
care about endian. I think it only uses it to layout bitfields within bytes/integers.
Heck -- given that we have no bitfields used between C and Modula-3, I think this
dependency can be removed already, just do the layout arbitrarily!


?- Jay


----------------------------------------
> Date: Wed, 27 Oct 2010 11:19:49 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] small problems bring up new node
>
> Quoting Jay K :
>
> > Olaf, bringing up new nodes I think finds small problems in the automation.
> >
> > new node: jaws1 which is Linux/x86
> >   (Rename it if you don't like it.)
> >
> > initial install worked in one attempt, good:
> > http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/
> >
> > building cm3cg worked in one attempt, good:
> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/
> >
> > but building the rest failed, for lack of "last ok" build:
> > http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull
>
> That hasn't been realluy automated in a generic fashion yet.
> I always had to perform several steps more or less manually due to
> different environments etc. If you can write a general boot or init
> job that will be great.
>
> The build and test jobs all expect valid cm3 package pool setups
> in current and lastok. That at least should be easy to automate.
>
> > I'm sure if I just copy stuff around it'll work.
> > Unless we need to start with a newer release,
> > which is a different matter if so.
> >
> > This node was cloned from xlinux and I just changed the node
> > name and node to ssh to.
>
> There are different variants of init jobs for different platforms.
> Maybe you just were unlucky to pick a rather old one :-/
>
> > (The great thing about a C backend is all this testing
> > across every architecture would all but disappear..)
>
> No, it wouldn't. We could neither be sure that the generated C code
> compiles with a native compiler (unless we require the same version
> of gcc everywhere) nor that it would perform in the same way on all
> platforms. That doesn't mean that a C backend wouldn't be a great
> extension, of course.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From dragisha at m3w.org  Wed Oct 27 23:41:19 2010
From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Wed, 27 Oct 2010 23:41:19 +0200
Subject: [M3devel] small problems bring up new node (autoconf????)
In-Reply-To: <COL101-W53C69CA2CF01060D50A5EBE6430@phx.gbl>
References: <COL101-W41A6C2863ED2F043F50D3E6430@phx.gbl>,
	<20101027111949.y1cqqsyfsowk80kk@mail.elegosoft.com>
	<COL101-W53C69CA2CF01060D50A5EBE6430@phx.gbl>
Message-ID: <A485C743-B052-4BB1-9E44-EF13F47B871D@m3w.org>

Autoconf will be used in future cm3????

On Oct 27, 2010, at 11:28 AM, Jay K wrote:

> As well, autoconf might subsume some of that.



From wagner at elegosoft.com  Fri Oct 29 14:11:34 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 29 Oct 2010 14:11:34 +0200
Subject: [M3devel] recent cm3cg regression
Message-ID: <20101029141134.7gx4toby80w4k0gs@mail.elegosoft.com>

recent m3cc changes lead to lots of compilation errors, e.g.

http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-AMD64_FREEBSD/133/console

please fix

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Fri Oct 29 21:16:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 29 Oct 2010 19:16:21 +0000
Subject: [M3devel] recent cm3cg regression
In-Reply-To: <20101029141134.7gx4toby80w4k0gs@mail.elegosoft.com>
References: <20101029141134.7gx4toby80w4k0gs@mail.elegosoft.com>
Message-ID: <COL101-W20AC67BB0B46D76B4C3BA4E6450@phx.gbl>


oops sorry I forgot to commit m3gty45.h.

?- Jay



----------------------------------------
> Date: Fri, 29 Oct 2010 14:11:34 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] recent cm3cg regression
>
> recent m3cc changes lead to lots of compilation errors, e.g.
>
> http://hudson.modula3.com:8080/view/cm3-current/job/cm3-current-m3cc-AMD64_FREEBSD/133/console
>
> please fix
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
 		 	   		  

From jay.krell at cornell.edu  Sun Oct 31 05:43:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 04:43:59 +0000
Subject: [M3devel] "looping to get all types declared first"
Message-ID: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>


There is this "replay" thing I put in the backend.
It isn't quite right.
 
 
I would like to have multiple passes, where if
all the types haven't been declared yet, non-type-declaration
operations do nothing.
 
There are approximately three approaches.
 
 1) the frontend front-loads all type declarations
so as soon as non-type declaration seen, that is the end,
ok to loop; I don't know if this is true.
 
 
 2) in each operand implementation, check if all the types
  have been declared yet and if not and if the operation
  isn't a declaration, immediately return
  This isn't entirely true. Some things like begin unit/procedure/block
  need to do anything, to track lexical location for building
  prefixes on type names, or somesuch.
 
 Actually, I think all the type data structures might need
to be in a linked list going from inner scope to outer scope
and searches have to search them in order and take the first hit. ?
 
 
 3) or, similarly, but the question is, do we loop
  over the serialized form, or do we first deserialize
  into an in-memory form, and then loop over that?
 
 
Those are my main questions:
   a) does the front end front-load declarations? I can trace a bit in cm3cg and guess.
   b) if not, do people prefer multiple passes over the serialized form or
   first deserialize into an in-memory form, and then loop over that
   c) change frontend to front-load declarations
 
 
My preference is b.
It is isn't the most efficient, but the efficiency should be plenty adequate.
 
 
I understand typeids are hashes, so scope is sort of irrelevant.
But typenames specifically are scoped.
 
 
 - Jay 		 	   		  

From jay.krell at cornell.edu  Sun Oct 31 08:20:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 07:20:37 +0000
Subject: [M3devel] va/loophole/integers
Message-ID: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>


When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.


I think this is wrong in multiple ways.


For 64bit targets, nothing should be done.
Backend can check that it is given equal types.
This might already be done.


A range check should be done.
Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.
Code that wants to ignore this can..well..it takes a bit if code I guess, but still.

Similarly for LONGCARD to CARDINAL

And then, still, I don't think loophole is appropriate.

Perhaps loophole in backend isn't meant to match up to loophole in the language?
I guess, maybe, but this seems...not intuitive.

In particular I tried making loophole use VIEW_CONVERT and I was look at the
affect here:

libm3/.../FilePosix.m3

PROCEDURE RegularFileSeek(
??? h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
? : INTEGER RAISES {OSError.E} =
? BEGIN
??? WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
????? IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
????? RETURN VAL(result, INTEGER)
??? END
? END RegularFileSeek;



(1034) call_direct procedure:Unix__lseek type:int64
(1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
(1036) store var:noname offset:0 src_t:int64 dst_t:int64
(1037) begin_block
(1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
(1039) load var:noname offset:0 src_t:int64 dst_t:int64
(1040) store var:result offset:0 src_t:int64 dst_t:int64
(1041) set_source_line 0x96(150)
(1042) load_integer type:int32 0
(1043) loophole type1:int32 type2:int64



and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.


Probably the backend should check that loophole is using two equal sized types, and then use view convert.
Though for now at least it has to deal with these integer conversions.


?- Jay

 		 	   		  

From hosking at cs.purdue.edu  Sun Oct 31 17:48:58 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 31 Oct 2010 12:48:58 -0400
Subject: [M3devel] "looping to get all types declared first"
In-Reply-To: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>
References: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>
Message-ID: <98707534-E63B-414E-BD43-508BB9A2C3D0@cs.purdue.edu>

I don't understand the purpose of all this.  Can't you just maintain one global table mapping type id to type?

On Oct 31, 2010, at 12:43 AM, Jay K wrote:

> 
> There is this "replay" thing I put in the backend.
> It isn't quite right.
> 
> 
> I would like to have multiple passes, where if
> all the types haven't been declared yet, non-type-declaration
> operations do nothing.
> 
> There are approximately three approaches.
> 
> 1) the frontend front-loads all type declarations
> so as soon as non-type declaration seen, that is the end,
> ok to loop; I don't know if this is true.
> 
> 
> 2) in each operand implementation, check if all the types
>  have been declared yet and if not and if the operation
>  isn't a declaration, immediately return
>  This isn't entirely true. Some things like begin unit/procedure/block
>  need to do anything, to track lexical location for building
>  prefixes on type names, or somesuch.
> 
> Actually, I think all the type data structures might need
> to be in a linked list going from inner scope to outer scope
> and searches have to search them in order and take the first hit. ?
> 
> 
> 3) or, similarly, but the question is, do we loop
>  over the serialized form, or do we first deserialize
>  into an in-memory form, and then loop over that?
> 
> 
> Those are my main questions:
>   a) does the front end front-load declarations? I can trace a bit in cm3cg and guess.
>   b) if not, do people prefer multiple passes over the serialized form or
>   first deserialize into an in-memory form, and then loop over that
>   c) change frontend to front-load declarations
> 
> 
> My preference is b.
> It is isn't the most efficient, but the efficiency should be plenty adequate.
> 
> 
> I understand typeids are hashes, so scope is sort of irrelevant.
> But typenames specifically are scoped.
> 
> 
> - Jay 		 	   		  



From hosking at cs.purdue.edu  Sun Oct 31 18:51:14 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sun, 31 Oct 2010 13:51:14 -0400
Subject: [M3devel] va/loophole/integers
In-Reply-To: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>
References: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>
Message-ID: <3D7DC9AE-0089-48AE-BA7D-6DB07BDD1F85@cs.purdue.edu>

On Oct 31, 2010, at 3:20 AM, Jay K wrote:

> When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.

Possibly.  LOOPHOLE in the language expects values with equal BITSIZE.  I used it originally because LOOPHOLE as implemented seemed to do the right thing.  Probably we should use widen/chop (as defined in M3CG_Ops.i3).

> I think this is wrong in multiple ways.
> 
> 
> For 64bit targets, nothing should be done.
> Backend can check that it is given equal types.
> This might already be done.

If they are same BITSIZE then loophole is appropriate, no?

> A range check should be done.

We have a range check in VAL:

      Expr.GetBounds (ce.args[0], minu, maxu);
      EVAL Type.GetBounds (t, mint, maxt);
      IF TInt.LT (minu, mint) THEN
        (* we need a lower bound check *)
        IF TInt.LT (maxt, maxu) THEN
          (* we also need an upper bound check *)
          ce.args[0] := CheckExpr.New (ce.args[0], mint, maxt,
                                          CG.RuntimeError.ValueOutOfRange);
          Expr.TypeCheck (ce.args[0], cs);
        ELSE
          ce.args[0] := CheckExpr.NewLower (ce.args[0], mint,
                                          CG.RuntimeError.ValueOutOfRange);
          Expr.TypeCheck (ce.args[0], cs);
        END;
      ELSIF TInt.LT (maxt, maxu) THEN
        (* we need an upper bound check *)
        ce.args[0] := CheckExpr.NewUpper (ce.args[0], maxt,
                                          CG.RuntimeError.ValueOutOfRange);
        Expr.TypeCheck (ce.args[0], cs);
      END;


> Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.

This *will* raise an exception if it doesn't fit.

> Code that wants to ignore this can..well..it takes a bit if code I guess, but still.
> Similarly for LONGCARD to CARDINAL

Should be the same.

> And then, still, I don't think loophole is appropriate.
> 
> Perhaps loophole in backend isn't meant to match up to loophole in the language?
> I guess, maybe, but this seems...not intuitive.

Perhaps we should use widen/chop?

> In particular I tried making loophole use VIEW_CONVERT and I was look at the
> affect here:
> 
> libm3/.../FilePosix.m3
> 
> PROCEDURE RegularFileSeek(
>     h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
>   : INTEGER RAISES {OSError.E} =
>   BEGIN
>     WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
>       IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
>       RETURN VAL(result, INTEGER)
>     END
>   END RegularFileSeek;
> 
> 
> 
> (1034) call_direct procedure:Unix__lseek type:int64
> (1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
> (1036) store var:noname offset:0 src_t:int64 dst_t:int64
> (1037) begin_block
> (1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
> (1039) load var:noname offset:0 src_t:int64 dst_t:int64
> (1040) store var:result offset:0 src_t:int64 dst_t:int64
> (1041) set_source_line 0x96(150)
> (1042) load_integer type:int32 0
> (1043) loophole type1:int32 type2:int64
> 
> 
> 
> and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.
> 
> 
> Probably the backend should check that loophole is using two equal sized types, and then use view convert.
> Though for now at least it has to deal with these integer conversions.
> 
> 
>  - Jay
> 
> 		 	   		  



From jay.krell at cornell.edu  Sun Oct 31 21:50:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 20:50:14 +0000
Subject: [M3devel] va/loophole/integers
In-Reply-To: <3D7DC9AE-0089-48AE-BA7D-6DB07BDD1F85@cs.purdue.edu>
References: <COL101-W865AFBC6ACF7CD10E0111E6470@phx.gbl>,
	<3D7DC9AE-0089-48AE-BA7D-6DB07BDD1F85@cs.purdue.edu>
Message-ID: <COL101-W1960B31CCD5A3F3A1CF8EE6470@phx.gbl>


I admit I didn't read all the code or try a test -- so the range check could be there already, yes.

?> LOOPHOLE in the language expects values with equal BITSIZE

Ok. So the assert I added is redundant, but that's ok, asserts usually are.

> Perhaps we should use widen/chop?

Sounds promising.

I admit I'm just not sure. The current code doesn't seem terrible.
General pattern: Lots of things are surprising (not intuitive) when first discovered.
But that doesn't make them wrong or unreasonable.

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sun, 31 Oct 2010 13:51:14 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] va/loophole/integers
>
> On Oct 31, 2010, at 3:20 AM, Jay K wrote:
>
> > When VAL is used to convert between INTEGER and LONGINT, the backend is given loophole.
>
> Possibly. LOOPHOLE in the language expects values with equal BITSIZE. I used it originally because LOOPHOLE as implemented seemed to do the right thing. Probably we should use widen/chop (as defined in M3CG_Ops.i3).
>
> > I think this is wrong in multiple ways.
> >
> >
> > For 64bit targets, nothing should be done.
> > Backend can check that it is given equal types.
> > This might already be done.
>
> If they are same BITSIZE then loophole is appropriate, no?
>
> > A range check should be done.
>
> We have a range check in VAL:
>
> Expr.GetBounds (ce.args[0], minu, maxu);
> EVAL Type.GetBounds (t, mint, maxt);
> IF TInt.LT (minu, mint) THEN
> (* we need a lower bound check *)
> IF TInt.LT (maxt, maxu) THEN
> (* we also need an upper bound check *)
> ce.args[0] := CheckExpr.New (ce.args[0], mint, maxt,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> ELSE
> ce.args[0] := CheckExpr.NewLower (ce.args[0], mint,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> END;
> ELSIF TInt.LT (maxt, maxu) THEN
> (* we need an upper bound check *)
> ce.args[0] := CheckExpr.NewUpper (ce.args[0], maxt,
> CG.RuntimeError.ValueOutOfRange);
> Expr.TypeCheck (ce.args[0], cs);
> END;
>
>
> > Truncating a LONGINT to a INTEGER should raise an exception if it doesn't fit.
>
> This *will* raise an exception if it doesn't fit.
>
> > Code that wants to ignore this can..well..it takes a bit if code I guess, but still.
> > Similarly for LONGCARD to CARDINAL
>
> Should be the same.
>
> > And then, still, I don't think loophole is appropriate.
> >
> > Perhaps loophole in backend isn't meant to match up to loophole in the language?
> > I guess, maybe, but this seems...not intuitive.
>
> Perhaps we should use widen/chop?
>
> > In particular I tried making loophole use VIEW_CONVERT and I was look at the
> > affect here:
> >
> > libm3/.../FilePosix.m3
> >
> > PROCEDURE RegularFileSeek(
> > h: RegularFile.T; origin: RegularFile.Origin; offset: INTEGER)
> > : INTEGER RAISES {OSError.E} =
> > BEGIN
> > WITH result = Unix.lseek(h.fd, VAL(offset, Utypes.off_t), ORD(origin)) DO
> > IF result < VAL(0, Utypes.off_t) THEN OSErrorPosix.Raise() END;
> > RETURN VAL(result, INTEGER)
> > END
> > END RegularFileSeek;
> >
> >
> >
> > (1034) call_direct procedure:Unix__lseek type:int64
> > (1035) declare_temp size:0x40(64) align:0x40(64) type:int64 in_memory:false
> > (1036) store var:noname offset:0 src_t:int64 dst_t:int64
> > (1037) begin_block
> > (1038) declare_local name:result size:0x40(64) align:0x40(64) type:int64 typeid:0x839F750E in_memory:false up_level:false 0x32(50)
> > (1039) load var:noname offset:0 src_t:int64 dst_t:int64
> > (1040) store var:result offset:0 src_t:int64 dst_t:int64
> > (1041) set_source_line 0x96(150)
> > (1042) load_integer type:int32 0
> > (1043) loophole type1:int32 type2:int64
> >
> >
> >
> > and, by the way, we still have no good story for files larger than 2GB or 4GB on 32bit targets using Rd/Wr.
> >
> >
> > Probably the backend should check that loophole is using two equal sized types, and then use view convert.
> > Though for now at least it has to deal with these integer conversions.
> >
> >
> > - Jay
> >
> >
>
 		 	   		  

From jay.krell at cornell.edu  Sun Oct 31 21:54:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 31 Oct 2010 20:54:34 +0000
Subject: [M3devel] "looping to get all types declared first"
In-Reply-To: <98707534-E63B-414E-BD43-508BB9A2C3D0@cs.purdue.edu>
References: <COL101-W4747DAE5C409070FEED7EFE6470@phx.gbl>,
	<98707534-E63B-414E-BD43-508BB9A2C3D0@cs.purdue.edu>
Message-ID: <COL101-W13EDB0642C9A0A6E24EE88E6470@phx.gbl>


> I don't understand the purpose of all this. Can't you just maintain one global table mapping type id to type?

The general problem is that types are used before they are declared.
Another problem is my ignorance of what is possible.

For example, is it possible to just no type on everything at first, just a struct lang_type with typeid,
and then walk the gcc trees repeatedly replacing those as possible?

Would that require, perhaps, setting unit_at_a_time = true, which is an optimization, but ok?

Or do all the types need to be correct upon initial tree construction?

If they have to be correct up front, it takes multiple passes through the type declarations due to
circularities or out-of-orders.

I have something in place for multiple passes, but it doesn't avoid building statements (non-declarations)
in the earlier passes.

Typenames are not amenable to one global table, but I'm not sure they matter at all.
I'm thinking the backend can basically ignore them entirely -- or at least not do anything new with them
in this effort to make the trees correctly typed.


?- Jay