From wagner at elegosoft.com  Mon May  3 17:19:16 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 03 May 2010 17:19:16 +0200
Subject: [M3devel] Solaris x86 support
In-Reply-To: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>
Message-ID: <20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>

Quoting Dagobert Michelsen <dam at opencsw.org>:

> Dear sirs,
>
> I would like to know if there is a version of cm3 for Solaris 10 x86
> available or planned.

Please see trac ticket https://projects.elego.de/cm3/ticket/1084.

This is the second request for CM3 on Solaris/x86.

I forwarded the first one to m3devel, but there has been no response
from any developer yet as far as I know.

As this is an open source project with volunteers working on the code,
there is no centrally controlled plan, and schedules often get updated;
however, I've added the request to the 5.9 milestone for the time being.

Let's see if anybody catches this one... please stay tuned :-)

Best regards,

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 May  3 17:59:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 3 May 2010 15:59:10 +0000
Subject: [M3devel] Solaris x86 support
In-Reply-To: <20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>
Message-ID: <COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>


If someone gives me ssh access to a Solaris machine, then I can do it.
It'd also be a good project for almost anyone to try.
Otherwise I'll get to it eventually.

?- Jay

----------------------------------------
> Date: Mon, 3 May 2010 17:19:16 +0200
> From: wagner at elegosoft.com
> To: dam at opencsw.org
> CC: m3devel at elego.de; m3-support at elego.de
> Subject: Re: [M3devel] Solaris x86 support
>
> Quoting Dagobert Michelsen :
>
>> Dear sirs,
>>
>> I would like to know if there is a version of cm3 for Solaris 10 x86
>> available or planned.
>
> Please see trac ticket https://projects.elego.de/cm3/ticket/1084.
>
> This is the second request for CM3 on Solaris/x86.
>
> I forwarded the first one to m3devel, but there has been no response
> from any developer yet as far as I know.
>
> As this is an open source project with volunteers working on the code,
> there is no centrally controlled plan, and schedules often get updated;
> however, I've added the request to the 5.9 milestone for the time being.
>
> Let's see if anybody catches this one... please stay tuned :-)
>
> Best regards,
>
> 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 May  3 18:15:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 3 May 2010 16:15:13 +0000
Subject: [M3devel] Solaris x86 support
In-Reply-To: <23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>
Message-ID: <COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>


jay or jaykrell or jkrell or whatever you want but tell me (and tell me machine name)
and hopefully your machine doesn't allow remote password logins, only ssh
Presumably you have a working cc and/or gcc.
I can make a local per-user one if needed, but I can probably only do that for gcc.
? Oddly the Solaris 10 x86 VM I had partly up this weekend came with gcc but not cc.
? Made me wonder if gcc is the way..

? - Jay

----------------------------------------
> CC: wagner at elegosoft.com; m3devel at elego.de; m3-support at elego.de
> From: dam at opencsw.org
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] Solaris x86 support
> Date: Mon, 3 May 2010 18:07:34 +0200
>
> Hi Jay,
>
> Am 03.05.2010 um 17:59 schrieb Jay K:
>> If someone gives me ssh access to a Solaris machine, then I can do it.
>> It'd also be a good project for almost anyone to try.
>> Otherwise I'll get to it eventually.
>
> Cool. I just need your intended username and ssh public key.
> Additionally,
> it would be nice if I could name your with the project at the usage
> page at
> 
>>
>
> Best regards
>
> -- Dago
>
>>
>> - Jay
>>
>> ----------------------------------------
>>> Date: Mon, 3 May 2010 17:19:16 +0200
>>> From: wagner at elegosoft.com
>>> To: dam at opencsw.org
>>> CC: m3devel at elego.de; m3-support at elego.de
>>> Subject: Re: [M3devel] Solaris x86 support
>>>
>>> Quoting Dagobert Michelsen :
>>>
>>>> Dear sirs,
>>>>
>>>> I would like to know if there is a version of cm3 for Solaris 10 x86
>>>> available or planned.
>>>
>>> Please see trac ticket https://projects.elego.de/cm3/ticket/1084.
>>>
>>> This is the second request for CM3 on Solaris/x86.
>>>
>>> I forwarded the first one to m3devel, but there has been no response
>>> from any developer yet as far as I know.
>>>
>>> As this is an open source project with volunteers working on the
>>> code,
>>> there is no centrally controlled plan, and schedules often get
>>> updated;
>>> however, I've added the request to the 5.9 milestone for the time
>>> being.
>>>
>>> Let's see if anybody catches this one... please stay tuned :-)
>>>
>>> Best regards,
>>>
>>> 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 --------------
A non-text attachment was scrubbed...
Name: id_dsa.pub
Type: application/octet-stream
Size: 600 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100503/6a23a00e/attachment.obj>

From bugs at elego.de  Mon May  3 21:34:44 2010
From: bugs at elego.de (CM3)
Date: Mon, 03 May 2010 19:34:44 -0000
Subject: [M3devel] [CM3] #1085: Trac Tickets get auto-discarded form
 cm3devel mailing list
Message-ID: <052.c12f607bc89a9ab27900ba1cc75174b6@elego.de>

#1085: Trac Tickets get auto-discarded form cm3devel mailing list
--------------------------------+-------------------------------------------
      Reporter:  mand@?         |        Owner:  wagner
          Type:  support        |       Status:  new   
      Priority:  medium         |    Milestone:        
     Component:  misc           |      Version:  none  
      Severity:  non-critical   |     Keywords:        
       Relnote:                 |          Org:        
Estimatedhours:  0              |        Hours:  0     
      Billable:  1              |   Totalhours:  0     
      Internal:  0              |  
--------------------------------+-------------------------------------------
Htr:
Open or modify a ticket


Fix:
- added "bugs at elego.de" to "auto-accept" list
- added "use_public_cc = true" to cm3 trac.ini


Env:


--------------------------------+-------------------------------------------
 - cc'd tickets from the cm3 trac get autodiscarded
 - no error message or reason given in notification mail
 - suspected causes:
     o bugs at elego.de is not amemeber
     o trac notification plugin sends cc's as bcc

-- 
Ticket URL: <http://projects.elego.de/cm3/ticket/1085>
CM3 <http://projects.elego.de/cm3>
Critical Mass Modula3 Compiler


From wagner at elegosoft.com  Tue May  4 10:23:42 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 04 May 2010 10:23:42 +0200
Subject: [M3devel] Fwd: Auto-discard notification
Message-ID: <20100504102342.ndbo7ov33ks8o8w4@mail.elegosoft.com>

FYI

mailed before subscription was processed...

----- Forwarded message from m3devel-bounces at elegosoft.com -----
     Date: Tue, 04 May 2010 09:18:59 +0200
     From: m3devel-bounces at elegosoft.com
Reply-To: m3devel-bounces at elegosoft.com
  Subject: Auto-discard notification
       To: m3devel-owner at elegosoft.com

The attached message has been automatically discarded.

----- End forwarded message -----

Date: Tue, 4 May 2010 09:11:07 +0200 (CEST)
Subject: some questions
From: Maksimiuk Darek <maxy at online.nl>
To: m3devel at elegosoft.com


Dear All,
  During last  weekend I decide to give a try and play with Modula-3  
language/environment.

  I have installed the  cm3 compiler and libraries on my WinXP box as  
well as on this
  little  PowerPC based machine called EFIKA  
(http://www.bplan-gmbh.de/output.php?PAGE_ID=124,
  http://www.bplan-gmbh.de/output.php?PAGE_ID=135). Unfortunately,  
this computer is no longer produced
  but still available in some places for sale.


  To get it working on the EFIKA I had to upgrade my Debian  
distribution from Etch to Lenny, and
  install the cm3  Linux PowerPC binaries. As far as I can tell, the  
whole process went without any glitches.

  This is the most important part (at least for me) - some questions ...

  1. Is there any (non-Reactor based) development environment for M3  
(emacs, eclipse, etc)?
  2. Are there any active projects that use M3?
  3. Did somebody benchmarked the cm3 compiler against C/C++ (I am  
interested in  the fp number crunching speed)?


  On the daily basis, I am using Matlab, Ada95, and ... Active Oberon  
(running A2 operating system from ETHZ).

  Thanks for your help.

  Regards,
    Darek
-- 
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 dabenavidesd at yahoo.es  Tue May  4 23:29:07 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 4 May 2010 21:29:07 +0000 (GMT)
Subject: [M3devel] Fwd: Auto-discard notification
In-Reply-To: <20100504102342.ndbo7ov33ks8o8w4@mail.elegosoft.com>
Message-ID: <326965.34591.qm@web23603.mail.ird.yahoo.com>

Hi:
welcome to M3 world, I think you will not repent of doing it.
About your questions:
1. Yes, there is a simple environment built on top of emacs (M3ide by Michel Dagenais http://www.professeurs.polymtl.ca/michel.dagenais/pkg/m3ide.tg) and Eclipse plugin too (M3clipse by Bert Laverman http://sourceforge.net/projects/m3clipse/) both are open source and would be nice to have some one who can use it.
2. Yes there are, many commercial, for research and open source projects too; a few worth to name here are the scripting VM based programming language UFO waiting for release, in the research arena there are others like the object oriented data base language Galileo and commercial ones there might be several ones but due trademark restrictions to publish their names some are not known.   
3. I have one reference worth to check in the side of the DEC SRC M3 vs. others a kind of idea of what you might want to know but could be outdated
http://www.dogfish.org/chris/papers/bakeoff/bakeoff.pdf
http://www.dogfish.org/chris/papers/bakeoff/bakeoff.tar.gz
In the new side you can always take times of programs and compare equivalent ones with time, though it might good to automate performance tests like the ones in the code above url tarball.

I hope it helps


--- El mar, 4/5/10, Olaf Wagner <wagner at elegosoft.com> escribi?:

> De: Olaf Wagner <wagner at elegosoft.com>
> Asunto: [M3devel] Fwd: Auto-discard notification
> Para: m3devel at elegosoft.com
> Fecha: martes, 4 de mayo, 2010 03:23
> FYI
> 
> mailed before subscription was processed...
> 
> ----- Forwarded message from m3devel-bounces at elegosoft.com
> -----
>     Date: Tue, 04 May 2010 09:18:59 +0200
>     From: m3devel-bounces at elegosoft.com
> Reply-To: m3devel-bounces at elegosoft.com
>  Subject: Auto-discard notification
>       To: m3devel-owner at elegosoft.com
> 
> The attached message has been automatically discarded.
> 
> ----- End forwarded message -----
> 
> Date: Tue, 4 May 2010 09:11:07 +0200 (CEST)
> Subject: some questions
> From: Maksimiuk Darek <maxy at online.nl>
> To: m3devel at elegosoft.com
> 
> 
> Dear All,
>  During last  weekend I decide to give a try and play
> with Modula-3 language/environment.
> 
>  I have installed the  cm3 compiler and libraries on
> my WinXP box as well as on this
>  little  PowerPC based machine called EFIKA (http://www.bplan-gmbh.de/output.php?PAGE_ID=124,
>  http://www.bplan-gmbh.de/output.php?PAGE_ID=135).
> Unfortunately, this computer is no longer produced
>  but still available in some places for sale.
> 
> 
>  To get it working on the EFIKA I had to upgrade my Debian
> distribution from Etch to Lenny, and
>  install the cm3  Linux PowerPC binaries. As far as I
> can tell, the whole process went without any glitches.
> 
>  This is the most important part (at least for me) - some
> questions ...
> 
>  1. Is there any (non-Reactor based) development
> environment for M3 (emacs, eclipse, etc)?
>  2. Are there any active projects that use M3?
>  3. Did somebody benchmarked the cm3 compiler against C/C++
> (I am interested in  the fp number crunching speed)?
> 
> 
>  On the daily basis, I am using Matlab, Ada95, and ...
> Active Oberon (running A2 operating system from ETHZ).
> 
>  Thanks for your help.
> 
>  Regards,
>    Darek
> --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 May  6 12:17:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 6 May 2010 10:17:43 +0000
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
 Sun cc vs. GNU cc?
In-Reply-To: <C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
Message-ID: <COL101-W178B634DF437CD791F310AE6F50@phx.gbl>


I thought I had sent a followup on this:
 https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html


Can you suggest precise platform name and precise other decisions?


This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
The provided machine's readme says we have Solaris 8, 9, 10 machines,
with multiple versions of Sun and GNU compilers.


Do I just declare that we only support Sun compiler?
Anyone who for some reason wants GNU gets to "rewrite" the config file and keep it to himself?
Or we somehow provide Sun and GNU "configurations" and user can pick one?


Do we have I386_SOLARIS_SUNCC and I386_SOLARIS_GNUCC?
or I386_SOLARIS_CC and I386_SOLARIS_GCC?

or I386_SOLARIS_SUN and I386_SOLARIS_GNU?




I wouldn't mind "helping" people and author the gcc support in quake.
  With some plan to move quake into cm3 in future.
But I don't want this to snowball into having to list extra identical platforms everywhere,
as has been the case for SOLsun and SOLgnu.
  Granted, platform-specific code is extremely rare now.


But the "one target, multiple configurations" of NT386/GNU/MINGNU did seem to get too messy/confusing.


 - Jay


From: hosking at cs.purdue.edu
Subject: Re: [M3devel] new target names -- SOLsun vs. SOLgnu?
Date: Sat, 17 Apr 2010 09:09:08 -0400
To: jay.krell at cornell.edu



Sounds reasonable.

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


On 17 Apr 2010, at 06:50, Jay K wrote:If we have targets, say, I386_NT, I386_CYGWIN, I386_MINGW, I386_LINUX, I386_FREEBSD, I386_NETBSD, SPARC32_SOLARIS or SPARC_SOLARIS..how does one capture the SOLsun vs. SOLgnu difference? SPARC32_SOLARIS_SUN vs. SPARC32_SOLARIS_GNU? SPARC_SOLARIS_SUNCC, SPARC_SOLARIS_GCC?
"target is underscore separated list of relevant names, usually two but not limited to two"?
 
 
Drop SOLgnu and just equate SPARC32_SOLARIS with SOLsun?
Given that the reason for SOLgnu was because cc was not bundled with OS at some point?
  But now gcc and cc are both bundled as I understand!
 
 
Do some sort of autoconfig, sensitive to the CC environment variable?
 That's actually pretty easy and pretty cheap. Not a terrible idea.
 
 
I'm not really pushing hard on this topic, just that I want to cross build Cygwin from non-NT and was hitting minor problems.
Mainly I want to see if Cygwin pthreads works now, now that the hanging test case got "rewritten", so I can drop the SchedulerPosix.m3 file which duplicates content verbatim out of ThreadPThread.m3..
 
 
 - Jay


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

From hosking at cs.purdue.edu  Thu May  6 15:35:26 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 6 May 2010 09:35:26 -0400
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
	Sun cc vs. GNU cc?
In-Reply-To: <COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
Message-ID: <40F00483-654B-4139-827F-5B0A6E466918@cs.purdue.edu>

Is it true that Sun CC is always available on Solaris these days?

On 6 May 2010, at 06:17, Jay K wrote:

> I thought I had sent a followup on this:
>  https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html
> 
> 
> Can you suggest precise platform name and precise other decisions?
> 
> 
> This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
> The provided machine's readme says we have Solaris 8, 9, 10 machines,
> with multiple versions of Sun and GNU compilers.
> 
> 
> Do I just declare that we only support Sun compiler?
> Anyone who for some reason wants GNU gets to "rewrite" the config file and keep it to himself?
> Or we somehow provide Sun and GNU "configurations" and user can pick one?
> 
> 
> Do we have I386_SOLARIS_SUNCC and I386_SOLARIS_GNUCC?
> or I386_SOLARIS_CC and I386_SOLARIS_GCC?
> or I386_SOLARIS_SUN and I386_SOLARIS_GNU?
> 
> 
> I wouldn't mind "helping" people and author the gcc support in quake.
>   With some plan to move quake into cm3 in future.
> But I don't want this to snowball into having to list extra identical platforms everywhere,
> as has been the case for SOLsun and SOLgnu.
>   Granted, platform-specific code is extremely rare now.
> 
> 
> But the "one target, multiple configurations" of NT386/GNU/MINGNU did seem to get too messy/confusing.
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Subject: Re: [M3devel] new target names -- SOLsun vs. SOLgnu?
> Date: Sat, 17 Apr 2010 09:09:08 -0400
> To: jay.krell at cornell.edu
> 
> Sounds reasonable.
> 
> 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 17 Apr 2010, at 06:50, Jay K wrote:
> 
> If we have targets, say, I386_NT, I386_CYGWIN, I386_MINGW, I386_LINUX, I386_FREEBSD, I386_NETBSD, SPARC32_SOLARIS or SPARC_SOLARIS..how does one capture the SOLsun vs. SOLgnu difference? SPARC32_SOLARIS_SUN vs. SPARC32_SOLARIS_GNU? SPARC_SOLARIS_SUNCC, SPARC_SOLARIS_GCC?
> "target is underscore separated list of relevant names, usually two but not limited to two"?
>  
>  
> Drop SOLgnu and just equate SPARC32_SOLARIS with SOLsun?
> Given that the reason for SOLgnu was because cc was not bundled with OS at some point?
>   But now gcc and cc are both bundled as I understand!
>  
>  
> Do some sort of autoconfig, sensitive to the CC environment variable?
>  That's actually pretty easy and pretty cheap. Not a terrible idea.
>  
>  
> I'm not really pushing hard on this topic, just that I want to cross build Cygwin from non-NT and was hitting minor problems.
> Mainly I want to see if Cygwin pthreads works now, now that the hanging test case got "rewritten", so I can drop the SchedulerPosix.m3 file which duplicates content verbatim out of ThreadPThread.m3..
>  
>  
>  - Jay
> 
> 
> 

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

From dam at opencsw.org  Thu May  6 15:51:43 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 6 May 2010 15:51:43 +0200
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
	Sun cc vs. GNU cc?
In-Reply-To: <40F00483-654B-4139-827F-5B0A6E466918@cs.purdue.edu>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
	<40F00483-654B-4139-827F-5B0A6E466918@cs.purdue.edu>
Message-ID: <3B937FEC-0A36-4A04-A943-7F1A1A5756F6@opencsw.org>

Hi Tony,

Am 06.05.2010 um 15:35 schrieb Tony Hosking:
> Is it true that Sun CC is always available on Solaris these days?

It is not bundled with the OS, but it can be downloaded separately for  
free.


Best regards

   -- Dago



From mika at async.async.caltech.edu  Thu May  6 22:01:19 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 06 May 2010 13:01:19 -0700
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
	Sun cc vs. GNU cc?
In-Reply-To: <COL101-W178B634DF437CD791F310AE6F50@phx.gbl> 
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
Message-ID: <20100506200119.099571A209B@async.async.caltech.edu>

Jay K writes:
>--_5e9c7792-d671-4ede-8a4b-673a7203ffec_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>I thought I had sent a followup on this:
> https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html
>
>
>Can you suggest precise platform name and precise other decisions?
>
>
>This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
>The provided machine's readme says we have Solaris 8=2C 9=2C 10 machines=2C
>with multiple versions of Sun and GNU compilers.
>
>
>Do I just declare that we only support Sun compiler?
>Anyone who for some reason wants GNU gets to "rewrite" the config file and =
>keep it to himself?
>Or we somehow provide Sun and GNU "configurations" and user can pick one?

Does Sun's cc (or whatever is needed of it to make CM3 work) come free
nowadays?  It used to be a pay package on Solaris.

    Mika


From jay.krell at cornell.edu  Thu May  6 22:13:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 6 May 2010 20:13:07 +0000
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu?
	I386_SOLARIS	Sun cc vs. GNU cc?
In-Reply-To: <20100506200119.099571A209B@async.async.caltech.edu>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>, ,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>,
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>,
	<20100506200119.099571A209B@async.async.caltech.edu>
Message-ID: <COL101-W455ADF4C96225C281BC2AAE6F50@phx.gbl>


Yes it is free of cost. But maybe people still prefer gcc for some reason?
e.g. they have some Linux/sparc assembly?
or use gcc extensions?
We generally don't do either in the Modula-3 libraries, since we already compile with Sun cc for Sparc.
 
Or for cross build purposes?
 That can be pretty powerful -- building a full gcc+ld cross toolset. I'm using that for VMS currently (for ld you have to use trunk, the support isn't in the latest release). Though binutils/ld/gas support is a little spotty outside of Linux, generally not as much as gcc. And you have to copy the headers/libraries from the target machine.
 
 
 - Jay



----------------------------------------
> To: jay.krell at cornell.edu
> Date: Thu, 6 May 2010 13:01:19 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS Sun cc vs. GNU cc?
>
> Jay K writes:
>>--_5e9c7792-d671-4ede-8a4b-673a7203ffec_
>>Content-Type: text/plain; charset="iso-8859-1"
>>Content-Transfer-Encoding: quoted-printable
>>
>>
>>I thought I had sent a followup on this:
>> https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html
>>
>>
>>Can you suggest precise platform name and precise other decisions?
>>
>>
>>This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
>>The provided machine's readme says we have Solaris 8=2C 9=2C 10 machines=2C
>>with multiple versions of Sun and GNU compilers.
>>
>>
>>Do I just declare that we only support Sun compiler?
>>Anyone who for some reason wants GNU gets to "rewrite" the config file and =
>>keep it to himself?
>>Or we somehow provide Sun and GNU "configurations" and user can pick one?
>
> Does Sun's cc (or whatever is needed of it to make CM3 work) come free
> nowadays? It used to be a pay package on Solaris.
>
> Mika 		 	   		  

From peter.mckinna at gmail.com  Sat May  8 06:22:12 2010
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sat, 8 May 2010 14:22:12 +1000
Subject: [M3devel] Compile Options
Message-ID: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>

Hey,

  Using -c to disable library or program generation does not seem to work.
Also how do you turn off debug symbol generation?
And the -O switch doesnt seem to optimise anything.

  Is it just me or the documentation.

Regards

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100508/835dbed7/attachment.html>

From hosking at cs.purdue.edu  Sat May  8 06:55:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 8 May 2010 00:55:10 -0400
Subject: [M3devel] Compile Options
In-Reply-To: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
Message-ID: <C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>

What target platform?

On 8 May 2010, at 00:22, Peter McKinna wrote:

> Hey,
> 
>   Using -c to disable library or program generation does not seem to work. Also how do you turn off debug symbol generation?
> And the -O switch doesnt seem to optimise anything.
> 
>   Is it just me or the documentation.
> 
> Regards
> 
> Peter



From jay.krell at cornell.edu  Sat May  8 06:58:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 04:58:40 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
Message-ID: <COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>


-O is the config files
It gets passed on to them and they may or may not pay attention.

Turning off symbol generation not something I'm very sympathetic too.
I realize it cuts I/O, build time, resulting binary size (possibly load/runtime,
depending on the load behavior of symbols). Though on Windows
the symbols go into separate files, greatly reducing any negative affect.
On one hand, you don't want to inhibit debugging,
but on the other, we don't have a good debugger story anyway.
Again, check the config files.

-c I don't know. Is it important?

?- Jay

________________________________
> Date: Sat, 8 May 2010 14:22:12 +1000
> From: peter.mckinna at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Compile Options
>
> Hey,
>
> Using -c to disable library or program generation does not seem to work. Also how do you turn off debug symbol generation?
> And the -O switch doesnt seem to optimise anything.
>
> Is it just me or the documentation.
>
>
> Regards
>
> Peter
 		 	   		  

From wagner at elegosoft.com  Sat May  8 12:40:04 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 08 May 2010 12:40:04 +0200
Subject: [M3devel] Compile Options
In-Reply-To: <COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>
Message-ID: <20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>

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

> -O is the config files
> It gets passed on to them and they may or may not pay attention.
>
> Turning off symbol generation not something I'm very sympathetic too.
> I realize it cuts I/O, build time, resulting binary size (possibly   
> load/runtime,
> depending on the load behavior of symbols). Though on Windows
> the symbols go into separate files, greatly reducing any negative affect.
> On one hand, you don't want to inhibit debugging,

Of course you may want to strip symbols for programs delivered to
customers.

> but on the other, we don't have a good debugger story anyway.

m3gdb works well on certain platforms.

> Again, check the config files.
>
> -c I don't know. Is it important?

The front end just includes some quake calls in the generated
m3make file for the options:

% less AMD64_FREEBSD/m3make.args
set_config_options ()
readonly _all = TRUE % cm3 -build
m3_optimize (TRUE)                  <----
m3_debug (TRUE)                     <----
M3_KEEP_FILES = TRUE
m3_compile_only ()                  <----
M3_MODE = "build"
include_dir ("../src")

At least optimize and debug used to work some time ago; I'm not
sure about compile-only.

Was something lost during the great config refactoring?
Can you please check that, Jay?

I think we shold implement the CLI as documented. We _might_ discuss
the value-add of -c (I've never used it).

We're probably missing regression tests for these simple command line
arguments, too.

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  Sat May  8 18:01:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 8 May 2010 12:01:12 -0400
Subject: [M3devel] Compile Options
In-Reply-To: <20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
Message-ID: <EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>

-O used to work in the old config files.
Did it get lost?

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 8 May 2010, at 06:40, Olaf Wagner wrote:

> Quoting Jay K <jay.krell at cornell.edu>:
> 
>> -O is the config files
>> It gets passed on to them and they may or may not pay attention.
>> 
>> Turning off symbol generation not something I'm very sympathetic too.
>> I realize it cuts I/O, build time, resulting binary size (possibly  load/runtime,
>> depending on the load behavior of symbols). Though on Windows
>> the symbols go into separate files, greatly reducing any negative affect.
>> On one hand, you don't want to inhibit debugging,
> 
> Of course you may want to strip symbols for programs delivered to
> customers.
> 
>> but on the other, we don't have a good debugger story anyway.
> 
> m3gdb works well on certain platforms.
> 
>> Again, check the config files.
>> 
>> -c I don't know. Is it important?
> 
> The front end just includes some quake calls in the generated
> m3make file for the options:
> 
> % less AMD64_FREEBSD/m3make.args
> set_config_options ()
> readonly _all = TRUE % cm3 -build
> m3_optimize (TRUE)                  <----
> m3_debug (TRUE)                     <----
> M3_KEEP_FILES = TRUE
> m3_compile_only ()                  <----
> M3_MODE = "build"
> include_dir ("../src")
> 
> At least optimize and debug used to work some time ago; I'm not
> sure about compile-only.
> 
> Was something lost during the great config refactoring?
> Can you please check that, Jay?
> 
> I think we shold implement the CLI as documented. We _might_ discuss
> the value-add of -c (I've never used it).
> 
> We're probably missing regression tests for these simple command line
> arguments, too.
> 
> 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/20100508/f9331286/attachment.html>

From jay.krell at cornell.edu  Sun May  9 00:21:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 22:21:59 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>,
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>,
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>,
	<EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>
Message-ID: <COL101-W4501E007067E4DA24A83D6E6F70@phx.gbl>


-O looks right for the vast majority of targets (Unix.common: *BSD, Solaris, Darwin, Linux, maybe not NT/Interix/Cygwin/VMS).
I'll adjust -g/-gstabs+ (PA64_HPUX never generates symbols currently, since it doesn't support stabs)
I have some more config file cleanup on deck: moving m3back_flags out of per-target and to per-architecture, though even that is necessary duplication


I propose also that -O should imply -O2, not -O3.
?-O2 seems to be heavily used in the wider world, -O3 not so much 
?For one thing, gcc itself defaults to building with -O2.

I have it like this:

if not defined("m3back_optimize")
?m3back_optimize = "-O2"
end

if not defined("m3back_debug")
?
m3back_debug = "-gstaus+"

end


and then
if optimize options += m3back_optimize end
if debug options += m3back_debug? end




individual users/platforms can override, such as PA64_HPUX setting m3back_debug = "" (maybe later to something else)
maybe we can shift to dwarf at some point too, that seems to be the favored format on most platforms


?- Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Sat, 8 May 2010 12:01:12 -0400
> To: wagner at elegosoft.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compile Options
>
>
>
> -O used to work in the old config files.
> Did it get lost?
>
>
> 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 8 May 2010, at 06:40, Olaf Wagner wrote:
>
> Quoting Jay K>:
>
> -O is the config files
> It gets passed on to them and they may or may not pay attention.
>
> Turning off symbol generation not something I'm very sympathetic too.
> I realize it cuts I/O, build time, resulting binary size (possibly load/runtime,
> depending on the load behavior of symbols). Though on Windows
> the symbols go into separate files, greatly reducing any negative affect.
> On one hand, you don't want to inhibit debugging,
>
> Of course you may want to strip symbols for programs delivered to
> customers.
>
> but on the other, we don't have a good debugger story anyway.
>
> m3gdb works well on certain platforms.
>
> Again, check the config files.
>
> -c I don't know. Is it important?
>
> The front end just includes some quake calls in the generated
> m3make file for the options:
>
> % less AMD64_FREEBSD/m3make.args
> set_config_options ()
> readonly _all = TRUE % cm3 -build
> m3_optimize (TRUE) <----
> m3_debug (TRUE) <----
> M3_KEEP_FILES = TRUE
> m3_compile_only () <----
> M3_MODE = "build"
> include_dir ("../src")
>
> At least optimize and debug used to work some time ago; I'm not
> sure about compile-only.
>
> Was something lost during the great config refactoring?
> Can you please check that, Jay?
>
> I think we shold implement the CLI as documented. We _might_ discuss
> the value-add of -c (I've never used it).
>
> We're probably missing regression tests for these simple command line
> arguments, too.
>
> 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 May  9 00:31:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 22:31:09 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <COL101-W4501E007067E4DA24A83D6E6F70@phx.gbl>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>, ,
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>, ,
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>, ,
	<EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>,
	<COL101-W4501E007067E4DA24A83D6E6F70@phx.gbl>
Message-ID: <COL101-W25C8957E8FB3C0461CD852E6F70@phx.gbl>


I assume currently -g can't be turned off, because cm3cfg.common:

proc set_config_options() is
??? m3_option("-why")?? %-- produce a listing that explains what's happening and why
??? m3_debug(TRUE)????? %-- produce object code with debugging symbols
??? M3_OPTIONS += "-w1" %-- produce "level 1" warnings
end

Which was probably always like that but I'm not sure, I only sampled one historical file just now.
We should maybe have -g0 to turn it off?

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; wagner at elegosoft.com
> Date: Sat, 8 May 2010 22:21:59 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compile Options
>
>
> -O looks right for the vast majority of targets (Unix.common: *BSD, Solaris, Darwin, Linux, maybe not NT/Interix/Cygwin/VMS).
> I'll adjust -g/-gstabs+ (PA64_HPUX never generates symbols currently, since it doesn't support stabs)
> I have some more config file cleanup on deck: moving m3back_flags out of per-target and to per-architecture, though even that is necessary duplication
>
>
> I propose also that -O should imply -O2, not -O3.
>  -O2 seems to be heavily used in the wider world, -O3 not so much
>  For one thing, gcc itself defaults to building with -O2.
>
> I have it like this:
>
> if not defined("m3back_optimize")
>  m3back_optimize = "-O2"
> end
>
> if not defined("m3back_debug")
>
> m3back_debug = "-gstaus+"
>
> end
>
>
> and then
> if optimize options += m3back_optimize end
> if debug options += m3back_debug  end
>
>
>
>
> individual users/platforms can override, such as PA64_HPUX setting m3back_debug = "" (maybe later to something else)
> maybe we can shift to dwarf at some point too, that seems to be the favored format on most platforms
>
>
>  - Jay
>
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Sat, 8 May 2010 12:01:12 -0400
>> To: wagner at elegosoft.com
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Compile Options
>>
>>
>>
>> -O used to work in the old config files.
>> Did it get lost?
>>
>>
>> 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 8 May 2010, at 06:40, Olaf Wagner wrote:
>>
>> Quoting Jay K>:
>>
>> -O is the config files
>> It gets passed on to them and they may or may not pay attention.
>>
>> Turning off symbol generation not something I'm very sympathetic too.
>> I realize it cuts I/O, build time, resulting binary size (possibly load/runtime,
>> depending on the load behavior of symbols). Though on Windows
>> the symbols go into separate files, greatly reducing any negative affect.
>> On one hand, you don't want to inhibit debugging,
>>
>> Of course you may want to strip symbols for programs delivered to
>> customers.
>>
>> but on the other, we don't have a good debugger story anyway.
>>
>> m3gdb works well on certain platforms.
>>
>> Again, check the config files.
>>
>> -c I don't know. Is it important?
>>
>> The front end just includes some quake calls in the generated
>> m3make file for the options:
>>
>> % less AMD64_FREEBSD/m3make.args
>> set_config_options ()
>> readonly _all = TRUE % cm3 -build
>> m3_optimize (TRUE) <----
>> m3_debug (TRUE) <----
>> M3_KEEP_FILES = TRUE
>> m3_compile_only () <----
>> M3_MODE = "build"
>> include_dir ("../src")
>>
>> At least optimize and debug used to work some time ago; I'm not
>> sure about compile-only.
>>
>> Was something lost during the great config refactoring?
>> Can you please check that, Jay?
>>
>> I think we shold implement the CLI as documented. We _might_ discuss
>> the value-add of -c (I've never used it).
>>
>> We're probably missing regression tests for these simple command line
>> arguments, too.
>>
>> 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  Sun May  9 01:43:09 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 08 May 2010 16:43:09 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu> 
References: <20100508220958.8EA242474003@birch.elegosoft.com>,
	<62B45315-F33E-4586-BCCE-CE57F5E307EA@cs.purdue.edu>
	<COL101-W455DE8BD33138D220620E6E6F70@phx.gbl>,
	<C7985D61-0C4C-44B8-ACBE-2548725E3153@cs.purdue.edu>
	<COL101-W94565E47A143953025584E6F70@phx.gbl>
	<6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu>
Message-ID: <20100508234309.937D21A2095@async.async.caltech.edu>

I've been following the discussion at a distance and am trying to understand
what problem is being guarded against?

The possibility that users change the signal mask?  Signal mask is not
part of Modula-3.  I think a programmer who messes with the signal mask
shouldn't expect Modula-3 to restore it for him when it switches threads,
processes exceptions, etc.

If you want to provide hooks for it that would be nice but I think it's
strictly optional.

"Correctness" should (as always) mean correctness w.r.t. the Green Book,
which makes no mention at all of signals... It does mention FloatMode
however (page 75).

    Mika

Tony Hosking writes:
>
>--Apple-Mail-78-848772270
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=us-ascii
>
>I think we can argue that a programmer should program around this using =
>TRY...FINALLY (i.e., even if they used FloatMode).
>
>So, I think we are safe with jmpbuf instead of sigjmpbuf.
>
>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 8 May 2010, at 18:56, Jay K wrote:
>
>>=20
>> Is "proper" saving/restoring as much as we can think of, or is it =
>fast, or is it matching Ada and C++, or .. ?
>> Ada and C++ (gnat and g++) have often/historically used =
>setjmp/longjmp.
>>   configure -enable-sjlj-exceptions
>> It might be interesting to see if they try to avoid the signal mask =
>versions when they use setjmp/longjmp.
>> Lately they use table-based unwinding on platforms that they can -- =
>which is to say, I *really* doubt
>> they save/restore the signal mask, but they might.
>>=20
>>=20
>>  - Jay
>>=20
>> ----------------------------------------
>>> Subject: Re: [M3commit] CVS Update: cm3
>>> From: hosking at cs.purdue.edu
>>> Date: Sat, 8 May 2010 18:51:18 -0400
>>> CC: jkrell at elego.de; m3commit at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>=20
>>>=20
>>>=20
>>> On 8 May 2010, at 18:38, Jay K wrote:
>>>=20
>>>> Or, understood, you really think we might throw around a signal mask =
>change?
>>>=20
>>> It's possible.
>>>=20
>>>> Realize also that sigsetjmp or setjmp, whichever we use, is called =
>incredibly often, and sigsetjmp is likely
>>>> much much slower. Also notice..this I'll have to check...have we =
>ever called sigsetjmp?
>>>> Well, no, I doubt it. But maybe setjmp vs. _setjmp.
>>>> Again though, this can be significantly slow.
>>>>=20
>>>>=20
>>>> Ultimately as well...see..I started this email without a firm =
>opinion, but now I'm "firming" toward the change I made.
>>>> Consider C++ exceptions. Consider libunwind. Consider the SPARC =
>stack walker (which I have to look at).
>>>> Do they save/restore signal masks? I doubt it. Maybe. We can look =
>into it. But I doubt it.
>>>=20
>>> We should confirm.
>>>=20
>>>> Raising an exception can indeed by slow. But entering a function =
>with finally (or destructors) should not be overly so.
>>>=20
>>> Ultimately, we should use proper stack unwinding wherever possible.
>>>=20
>>>>=20
>>>>=20
>>>> - Jay
>>>>=20
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Sat, 8 May 2010 18:28:36 -0400
>>>>> To: jkrell at elego.de
>>>>> CC: m3commit at elegosoft.com
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>=20
>>>>> Ah, now I remember. sigjmpbuf is important for unwinding on =
>exception to make sure that if we unwind through a frame where the =
>programmer changed the signal mask that we also restore the signal mask =
>of the caller. I think you also probably break things like FloatMode by =
>not restoring the signal mask properly.
>>>>>=20
>>>>> On 9 May 2010, at 00:09, Jay Krell wrote:
>>>>>=20
>>>>>> CVSROOT: /usr/cvs
>>>>>> Changes by: jkrell at birch. 10/05/09 00:09:58
>>>>>>=20
>>>>>> Modified files:
>>>>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3
>>>>>>=20
>>>>>> Log message:
>>>>>> add SPARC32_SOLARIS
>>>>>>=20
>>>>>> correct jmpbuf sizes for I386_SOLARIS, AMD64_SOLARIS
>>>>>> notice again that jmpbuf is much much smaller than sigjmpbuf,
>>>>>> and this is jmpbuf; specifically:
>>>>>> I386_SOLARIS jmpbuf 40 bytes with 4 align
>>>>>> AMD64_SOLARIS jmpbuf 64 bytes with 8 align
>>>>>> I386_SOLARIS sigjmpbuf 512 bytes with 4 align
>>>>>> AMD64_SOLARIS sigjmpbuf 1024 bytes with 8 align
>>>>>>=20
>>>>>> remove some level of heap allocation of calling conventions
>>>>>>=20
>>>>>> accept all calling conventions for all targets
>>>>>> Only NT386 has calling conventions, and it *highly* likely
>>>>>> the only target ever to have them, therefore the mechanism
>>>>>> does not need to be further generalized. (MIPS32 has two
>>>>>> ABIs, but those will probably be two targets)
>>>>>> This might let us save some unnecessary forking of *.i3 files.
>>>>>> The initialization here can be further streamlined.
>>>>>>=20
>>>>>> shrink SOLgnu/SOLsun from sigjmpbuf to jmpbuf
>>>>>> I'm not sure we use this though since we have a stack walker.
>>>>>> fix SPARC64_SOLARIS too to be smaller
>>>>>>=20
>>>>>> SPARC32_SOLARIS
>>>>>> jmpbuf size: 48
>>>>>> sigjmpbuf size: 76
>>>>>> alignment: 4 4
>>>>>>=20
>>>>>> SPARC64_SOLARIS
>>>>>> jmpbuf size: 96
>>>>>> sigjmpbuf size: 152
>>>>>> alignment: 8 8
>>>>>=20
>>>>=20
>>>=20
>> 		 	   		 =20
>
>
>--Apple-Mail-78-848772270
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/html;
>	charset=us-ascii
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I =
>think we can argue that a programmer should program around this using =
>TRY...FINALLY (i.e., even if they used =
>FloatMode).<div><br></div><div>So, I think we are safe with jmpbuf =
>instead of sigjmpbuf.<br><div><br><div>
><span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
>auto; text-indent: 0px; text-transform: none; white-space: normal; =
>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF"><font =
>class=3D"Apple-style-span" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Antony =
>Hosking</span></span></font></font><font class=3D"Apple-style-span" =
>face=3D"Gill Sans"><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-converted-space">&nbsp;</span>|<span =
>class=3D"Apple-converted-space">&nbsp;</span></span></span><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; "><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; =
>">Associate Professor</span></span><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; "><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; ">&nbsp;| Computer Science | Purdue =
>University</span></span></font></div><div><font class=3D"Apple-style-span"=
> face=3D"GillSans-Light"><span class=3D"Apple-style-span" =
>style=3D"font-family: GillSans-Light; ">305 N. University Street | West =
>Lafayette | IN 47907 | USA</span></font></div><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Office</span></span></font><font =
>class=3D"Apple-style-span" face=3D"GillSans-Light"><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; =
>">&nbsp;+1 765 494 6001 |<span =
>class=3D"Apple-converted-space">&nbsp;</span></span></span></font><font =
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Mobile</span></span></font><font =
>class=3D"Apple-style-span" face=3D"GillSans-Light"><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-converted-space">&nbsp;</span>+1 765 427 =
>5484</span></span></font></div><div><font class=3D"Apple-style-span" =
>face=3D"GillSans-Light"><br =
>class=3D"khtml-block-placeholder"></font></div></span></span></span></span=
>></span></span></span><br =
>class=3D"Apple-interchange-newline"></span></div></span></span><br =
>class=3D"Apple-interchange-newline">
></div>
><br><div><div>On 8 May 2010, at 18:56, Jay K wrote:</div><br =
>class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><br>Is =
>"proper" saving/restoring as much as we can think of, or is it fast, or =
>is it matching Ada and C++, or .. ?<br>Ada and C++ (gnat and g++) have =
>often/historically used setjmp/longjmp.<br>&nbsp; configure =
>-enable-sjlj-exceptions<br>It might be interesting to see if they try to =
>avoid the signal mask versions when they use setjmp/longjmp.<br>Lately =
>they use table-based unwinding on platforms that they can -- which is to =
>say, I *really* doubt<br>they save/restore the signal mask, but they =
>might.<br><br><br>&nbsp;- =
>Jay<br><br>----------------------------------------<br><blockquote =
>type=3D"cite">Subject: Re: [M3commit] CVS Update: =
>cm3<br></blockquote><blockquote type=3D"cite">From: <a =
>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu</a><br></block=
>quote><blockquote type=3D"cite">Date: Sat, 8 May 2010 18:51:18 =
>-0400<br></blockquote><blockquote type=3D"cite">CC: <a =
>href=3D"mailto:jkrell at elego.de">jkrell at elego.de</a>; <a =
>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com</a><br></blo=
>ckquote><blockquote type=3D"cite">To: <a =
>href=3D"mailto:jay.krell at cornell.edu">jay.krell at cornell.edu</a><br></block=
>quote><blockquote type=3D"cite"><br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">On 8 May 2010, =
>at 18:38, Jay K wrote:<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">Or, understood, you really think we might throw around a =
>signal mask change?<br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">It's =
>possible.<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">Realize also that sigsetjmp or setjmp, whichever we use, =
>is called incredibly often, and sigsetjmp is =
>likely<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">much much slower. Also notice..this I'll have to =
>check...have we ever called =
>sigsetjmp?<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Well, no, I doubt it. But maybe =
>setjmp vs. _setjmp.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Again though, this can be =
>significantly slow.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Ultimately as well...see..I =
>started this email without a firm opinion, but now I'm "firming" toward =
>the change I made.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Consider C++ exceptions. =
>Consider libunwind. Consider the SPARC stack walker (which I have to =
>look at).<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Do they save/restore signal =
>masks? I doubt it. Maybe. We can look into it. But I doubt =
>it.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">We should =
>confirm.<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">Raising an exception can indeed by slow. But entering a =
>function with finally (or destructors) should not be overly =
>so.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">Ultimately, we =
>should use proper stack unwinding wherever =
>possible.<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">- =
>Jay<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite">----------------------------------------<br></blockquote></b=
>lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite">From: <a =
>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu</a><br></block=
>quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Date: Sat, 8 May 2010 18:28:36 =
>-0400<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To: <a =
>href=3D"mailto:jkrell at elego.de">jkrell at elego.de</a><br></blockquote></bloc=
>kquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">CC: <a =
>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com</a><br></blo=
>ckquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Subject: Re: [M3commit] CVS =
>Update: cm3<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Ah, =
>now I remember. sigjmpbuf is important for unwinding on exception to =
>make sure that if we unwind through a frame where the programmer changed =
>the signal mask that we also restore the signal mask of the caller. I =
>think you also probably break things like FloatMode by not restoring the =
>signal mask =
>properly.<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">On 9 =
>May 2010, at 00:09, Jay Krell =
>wrote:<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">CVSROOT: =
>/usr/cvs<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Changes by: jkrell at birch. =
>10/05/09 =
>00:09:58<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Modified =
>files:<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">cm3/m3-sys/m3middle/src/: =
>Target.i3 =
>Target.m3<br></blockquote></blockquote></blockquote></blockquote><blockquo=
>te type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Log =
>message:<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">add =
>SPARC32_SOLARIS<br></blockquote></blockquote></blockquote></blockquote><bl=
>ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">correct jmpbuf sizes for =
>I386_SOLARIS, =
>AMD64_SOLARIS<br></blockquote></blockquote></blockquote></blockquote><bloc=
>kquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">notice again that jmpbuf is much =
>much smaller than =
>sigjmpbuf,<br></blockquote></blockquote></blockquote></blockquote><blockqu=
>ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">and this is jmpbuf; =
>specifically:<br></blockquote></blockquote></blockquote></blockquote><bloc=
>kquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">I386_SOLARIS jmpbuf 40 bytes =
>with 4 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">AMD64_SOLARIS jmpbuf 64 bytes =
>with 8 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">I386_SOLARIS sigjmpbuf 512 bytes =
>with 4 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">AMD64_SOLARIS sigjmpbuf 1024 =
>bytes with 8 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">remove some level of heap =
>allocation of calling =
>conventions<br></blockquote></blockquote></blockquote></blockquote><blockq=
>uote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">accept all calling conventions =
>for all =
>targets<br></blockquote></blockquote></blockquote></blockquote><blockquote=
> type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Only NT386 has calling =
>conventions, and it *highly* =
>likely<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">the only target ever to have =
>them, therefore the =
>mechanism<br></blockquote></blockquote></blockquote></blockquote><blockquo=
>te type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">does not need to be further =
>generalized. (MIPS32 has =
>two<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">ABIs, but those will probably be =
>two =
>targets)<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">This might let us save some =
>unnecessary forking of *.i3 =
>files.<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">The initialization here can be =
>further =
>streamlined.<br></blockquote></blockquote></blockquote></blockquote><block=
>quote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">shrink SOLgnu/SOLsun from =
>sigjmpbuf to =
>jmpbuf<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">I'm not sure we use this though =
>since we have a stack =
>walker.<br></blockquote></blockquote></blockquote></blockquote><blockquote=
> type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">fix SPARC64_SOLARIS too to be =
>smaller<br></blockquote></blockquote></blockquote></blockquote><blockquote=
> type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite">SPARC32_SOLARIS<br></blockquote></blockquote></blockquote></=
>blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote=
> type=3D"cite"><blockquote type=3D"cite">jmpbuf size: =
>48<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">sigjmpbuf size: =
>76<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">alignment: 4 =
>4<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite">SPARC64_SOLARIS<br></blockquote></blockquote></blockquote></=
>blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote=
> type=3D"cite"><blockquote type=3D"cite">jmpbuf size: =
>96<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">sigjmpbuf size: =
>152<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">alignment: 8 =
>8<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote> <span class=3D"Apple-tab-span" =
>style=3D"white-space:pre">	</span><span class=3D"Apple-tab-span" =
>style=3D"white-space:pre">	</span> <span class=3D"Apple-tab-span" =
>style=3D"white-space:pre">	</span> &nbsp;&nbsp;<span =
>class=3D"Apple-tab-span" style=3D"white-space:pre">	</span><span =
>class=3D"Apple-tab-span" style=3D"white-space:pre">	</span> =
>&nbsp;<br></div></blockquote></div><br></div></div></body></html>=
>
>--Apple-Mail-78-848772270--


From jay.krell at cornell.edu  Sun May  9 01:49:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 23:49:13 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20100508234309.937D21A2095@async.async.caltech.edu>
References: <20100508220958.8EA242474003@birch.elegosoft.com>, ,
	<62B45315-F33E-4586-BCCE-CE57F5E307EA@cs.purdue.edu>,
	<COL101-W455DE8BD33138D220620E6E6F70@phx.gbl>, ,
	<C7985D61-0C4C-44B8-ACBE-2548725E3153@cs.purdue.edu>,
	<COL101-W94565E47A143953025584E6F70@phx.gbl>,
	<6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu>,
	<20100508234309.937D21A2095@async.async.caltech.edu>
Message-ID: <COL101-W487024C8B81D4B8120C348E6F70@phx.gbl>


It's not a closed system. Modula-3 can call C can call C++ can call Modula-3, etc., and they can call raise exceptions.
I'm not sure what the C exception story is on all platforms, but at least on Windows there is RaiseException.

Green book doesn't mention m3-libs/m3core/src/Unix, but it exists anyway.

?- Jay

----------------------------------------
> To: hosking at cs.purdue.edu
> Date: Sat, 8 May 2010 16:43:09 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> I've been following the discussion at a distance and am trying to understand
> what problem is being guarded against?
>
> The possibility that users change the signal mask? Signal mask is not
> part of Modula-3. I think a programmer who messes with the signal mask
> shouldn't expect Modula-3 to restore it for him when it switches threads,
> processes exceptions, etc.
>
> If you want to provide hooks for it that would be nice but I think it's
> strictly optional.
>
> "Correctness" should (as always) mean correctness w.r.t. the Green Book,
> which makes no mention at all of signals... It does mention FloatMode
> however (page 75).
>
> Mika
>
> Tony Hosking writes:
>>
>>--Apple-Mail-78-848772270
>>Content-Transfer-Encoding: quoted-printable
>>Content-Type: text/plain;
>> charset=us-ascii
>>
>>I think we can argue that a programmer should program around this using =
>>TRY...FINALLY (i.e., even if they used FloatMode).
>>
>>So, I think we are safe with jmpbuf instead of sigjmpbuf.
>>
>>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 8 May 2010, at 18:56, Jay K wrote:
>>
>>>=20
>>> Is "proper" saving/restoring as much as we can think of, or is it =
>>fast, or is it matching Ada and C++, or .. ?
>>> Ada and C++ (gnat and g++) have often/historically used =
>>setjmp/longjmp.
>>> configure -enable-sjlj-exceptions
>>> It might be interesting to see if they try to avoid the signal mask =
>>versions when they use setjmp/longjmp.
>>> Lately they use table-based unwinding on platforms that they can -- =
>>which is to say, I *really* doubt
>>> they save/restore the signal mask, but they might.
>>>=20
>>>=20
>>> - Jay
>>>=20
>>> ----------------------------------------
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sat, 8 May 2010 18:51:18 -0400
>>>> CC: jkrell at elego.de; m3commit at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>=20
>>>>=20
>>>>=20
>>>> On 8 May 2010, at 18:38, Jay K wrote:
>>>>=20
>>>>> Or, understood, you really think we might throw around a signal mask =
>>change?
>>>>=20
>>>> It's possible.
>>>>=20
>>>>> Realize also that sigsetjmp or setjmp, whichever we use, is called =
>>incredibly often, and sigsetjmp is likely
>>>>> much much slower. Also notice..this I'll have to check...have we =
>>ever called sigsetjmp?
>>>>> Well, no, I doubt it. But maybe setjmp vs. _setjmp.
>>>>> Again though, this can be significantly slow.
>>>>>=20
>>>>>=20
>>>>> Ultimately as well...see..I started this email without a firm =
>>opinion, but now I'm "firming" toward the change I made.
>>>>> Consider C++ exceptions. Consider libunwind. Consider the SPARC =
>>stack walker (which I have to look at).
>>>>> Do they save/restore signal masks? I doubt it. Maybe. We can look =
>>into it. But I doubt it.
>>>>=20
>>>> We should confirm.
>>>>=20
>>>>> Raising an exception can indeed by slow. But entering a function =
>>with finally (or destructors) should not be overly so.
>>>>=20
>>>> Ultimately, we should use proper stack unwinding wherever possible.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> - Jay
>>>>>=20
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Sat, 8 May 2010 18:28:36 -0400
>>>>>> To: jkrell at elego.de
>>>>>> CC: m3commit at elegosoft.com
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>=20
>>>>>> Ah, now I remember. sigjmpbuf is important for unwinding on =
>>exception to make sure that if we unwind through a frame where the =
>>programmer changed the signal mask that we also restore the signal mask =
>>of the caller. I think you also probably break things like FloatMode by =
>>not restoring the signal mask properly.
>>>>>>=20
>>>>>> On 9 May 2010, at 00:09, Jay Krell wrote:
>>>>>>=20
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: jkrell at birch. 10/05/09 00:09:58
>>>>>>>=20
>>>>>>> Modified files:
>>>>>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3
>>>>>>>=20
>>>>>>> Log message:
>>>>>>> add SPARC32_SOLARIS
>>>>>>>=20
>>>>>>> correct jmpbuf sizes for I386_SOLARIS, AMD64_SOLARIS
>>>>>>> notice again that jmpbuf is much much smaller than sigjmpbuf,
>>>>>>> and this is jmpbuf; specifically:
>>>>>>> I386_SOLARIS jmpbuf 40 bytes with 4 align
>>>>>>> AMD64_SOLARIS jmpbuf 64 bytes with 8 align
>>>>>>> I386_SOLARIS sigjmpbuf 512 bytes with 4 align
>>>>>>> AMD64_SOLARIS sigjmpbuf 1024 bytes with 8 align
>>>>>>>=20
>>>>>>> remove some level of heap allocation of calling conventions
>>>>>>>=20
>>>>>>> accept all calling conventions for all targets
>>>>>>> Only NT386 has calling conventions, and it *highly* likely
>>>>>>> the only target ever to have them, therefore the mechanism
>>>>>>> does not need to be further generalized. (MIPS32 has two
>>>>>>> ABIs, but those will probably be two targets)
>>>>>>> This might let us save some unnecessary forking of *.i3 files.
>>>>>>> The initialization here can be further streamlined.
>>>>>>>=20
>>>>>>> shrink SOLgnu/SOLsun from sigjmpbuf to jmpbuf
>>>>>>> I'm not sure we use this though since we have a stack walker.
>>>>>>> fix SPARC64_SOLARIS too to be smaller
>>>>>>>=20
>>>>>>> SPARC32_SOLARIS
>>>>>>> jmpbuf size: 48
>>>>>>> sigjmpbuf size: 76
>>>>>>> alignment: 4 4
>>>>>>>=20
>>>>>>> SPARC64_SOLARIS
>>>>>>> jmpbuf size: 96
>>>>>>> sigjmpbuf size: 152
>>>>>>> alignment: 8 8
>>>>>>=20
>>>>>=20
>>>>=20
>>> =20
>>
>>
>>--Apple-Mail-78-848772270
>>Content-Transfer-Encoding: quoted-printable
>>Content-Type: text/html;
>> charset=us-ascii
>>
>>>>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I =
>>think we can argue that a programmer should program around this using =
>>TRY...FINALLY (i.e., even if they used =
>>FloatMode).
So, I think we are safe with jmpbuf =
>>instead of sigjmpbuf.


>>>>color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
>>auto; text-indent: 0px; text-transform: none; white-space: normal; =
>>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>>-webkit-border-vertical-spacing: 0px; =
>>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>>auto; -webkit-text-stroke-width: 0; ">>>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>>font-family: Helvetica; font-size: 12px; font-style: normal; =
>>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>>line-height: normal; -webkit-text-decorations-in-effect: none; =
>>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">>>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>>-webkit-line-break: after-white-space; ">>>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>>font-family: Helvetica; font-size: 12px; font-style: normal; =
>>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>>line-height: normal; -webkit-text-decorations-in-effect: none; =
>>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" color=3D"#0000FF">>>class=3D"Apple-style-span" face=3D"Gill Sans">>>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>>'Gill Sans'; ">>>0, 255); font-family: 'Gill Sans'; ">Antony =
>>Hosking>>face=3D"Gill Sans">>>'Gill Sans'; ">>>'Gill Sans'; ">?|>>class=3D"Apple-converted-space">?>>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; ">>>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; =
>>">Associate Professor>>style=3D"font-family: 'Gill Sans'; ">>>style=3D"font-family: 'Gill Sans'; ">?| Computer Science | Purdue =
>>University>> face=3D"GillSans-Light">>>style=3D"font-family: GillSans-Light; ">305 N. University Street | West =
>>Lafayette | IN 47907 | USA>>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans">>>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>>'Gill Sans'; ">>>0, 255); font-family: 'Gill Sans'; ">Office>>class=3D"Apple-style-span" face=3D"GillSans-Light">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; =
>>">?+1 765 494 6001 |>>class=3D"Apple-converted-space">?>>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans">>>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>>'Gill Sans'; ">>>0, 255); font-family: 'Gill Sans'; ">Mobile>>class=3D"Apple-style-span" face=3D"GillSans-Light">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">>>class=3D"Apple-converted-space">?+1 765 427 =
>>5484>>face=3D"GillSans-Light">
>>class=3D"khtml-block-placeholder">
>>>
>>class=3D"Apple-interchange-newline">
>>class=3D"Apple-interchange-newline">
>>
>>
On 8 May 2010, at 18:56, Jay K wrote:
>>class=3D"Apple-interchange-newline">
Is =
>>"proper" saving/restoring as much as we can think of, or is it fast, or =
>>is it matching Ada and C++, or .. ?
Ada and C++ (gnat and g++) have =
>>often/historically used setjmp/longjmp.
? configure =
>>-enable-sjlj-exceptions
It might be interesting to see if they try to =
>>avoid the signal mask versions when they use setjmp/longjmp.
Lately =
>>they use table-based unwinding on platforms that they can -- which is to =
>>say, I *really* doubt
they save/restore the signal mask, but they =
>>might.


?- =
>>Jay

----------------------------------------
>>type=3D"cite">Subject: Re: [M3commit] CVS Update: =
>>cm3
From:>>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu

>>quote>Date: Sat, 8 May 2010 18:51:18 =
>>-0400
CC:>>href=3D"mailto:jkrell at elego.de">jkrell at elego.de;>>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com

>>ckquote>To:>>href=3D"mailto:jay.krell at cornell.edu">jay.krell at cornell.edu

>>quote>
>>type=3D"cite">
>>type=3D"cite">
On 8 May 2010, =
>>at 18:38, Jay K wrote:
>>type=3D"cite">
>>type=3D"cite">Or, understood, you really think we might throw around a =
>>signal mask change?
>>type=3D"cite">
It's =
>>possible.
>>type=3D"cite">
>>type=3D"cite">Realize also that sigsetjmp or setjmp, whichever we use, =
>>is called incredibly often, and sigsetjmp is =
>>likely
>>type=3D"cite">much much slower. Also notice..this I'll have to =
>>check...have we ever called =
>>sigsetjmp?
>>type=3D"cite">Well, no, I doubt it. But maybe =
>>setjmp vs. _setjmp.
>>type=3D"cite">Again though, this can be =
>>significantly slow.
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">Ultimately as well...see..I =
>>started this email without a firm opinion, but now I'm "firming" toward =
>>the change I made.
>>type=3D"cite">Consider C++ exceptions. =
>>Consider libunwind. Consider the SPARC stack walker (which I have to =
>>look at).
>>type=3D"cite">Do they save/restore signal =
>>masks? I doubt it. Maybe. We can look into it. But I doubt =
>>it.
>>type=3D"cite">
We should =
>>confirm.
>>type=3D"cite">
>>type=3D"cite">Raising an exception can indeed by slow. But entering a =
>>function with finally (or destructors) should not be overly =
>>so.
>>type=3D"cite">
Ultimately, we =
>>should use proper stack unwinding wherever =
>>possible.
>>type=3D"cite">
>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">- =
>>Jay
>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">----------------------------------------

>>lockquote>>>type=3D"cite">From:>>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu

>>quote>>>type=3D"cite">Date: Sat, 8 May 2010 18:28:36 =
>>-0400
>>type=3D"cite">To:>>href=3D"mailto:jkrell at elego.de">jkrell at elego.de

>>kquote>>>type=3D"cite">CC:>>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com

>>ckquote>>>type=3D"cite">Subject: Re: [M3commit] CVS =
>>Update: cm3
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">Ah, =
>>now I remember. sigjmpbuf is important for unwinding on exception to =
>>make sure that if we unwind through a frame where the programmer changed =
>>the signal mask that we also restore the signal mask of the caller. I =
>>think you also probably break things like FloatMode by not restoring the =
>>signal mask =
>>properly.
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">On 9 =
>>May 2010, at 00:09, Jay Krell =
>>wrote:
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">CVSROOT: =
>>/usr/cvs

>>e type=3D"cite">>>type=3D"cite">Changes by: jkrell at birch. =
>>10/05/09 =
>>00:09:58

>>e type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">Modified =
>>files:
>>type=3D"cite">>>type=3D"cite">cm3/m3-sys/m3middle/src/: =
>>Target.i3 =
>>Target.m3

>>te type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">Log =
>>message:

>>e type=3D"cite">>>type=3D"cite">add =
>>SPARC32_SOLARIS

>>ockquote type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">correct jmpbuf sizes for =
>>I386_SOLARIS, =
>>AMD64_SOLARIS

>>kquote type=3D"cite">>>type=3D"cite">notice again that jmpbuf is much =
>>much smaller than =
>>sigjmpbuf,

>>ote type=3D"cite">>>type=3D"cite">and this is jmpbuf; =
>>specifically:

>>kquote type=3D"cite">>>type=3D"cite">I386_SOLARIS jmpbuf 40 bytes =
>>with 4 =
>>align
>>type=3D"cite">>>type=3D"cite">AMD64_SOLARIS jmpbuf 64 bytes =
>>with 8 =
>>align
>>type=3D"cite">>>type=3D"cite">I386_SOLARIS sigjmpbuf 512 bytes =
>>with 4 =
>>align
>>type=3D"cite">>>type=3D"cite">AMD64_SOLARIS sigjmpbuf 1024 =
>>bytes with 8 =
>>align
>>type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">remove some level of heap =
>>allocation of calling =
>>conventions

>>uote type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">accept all calling conventions =
>>for all =
>>targets

>> type=3D"cite">>>type=3D"cite">Only NT386 has calling =
>>conventions, and it *highly* =
>>likely
>>type=3D"cite">>>type=3D"cite">the only target ever to have =
>>them, therefore the =
>>mechanism

>>te type=3D"cite">>>type=3D"cite">does not need to be further =
>>generalized. (MIPS32 has =
>>two
>>type=3D"cite">>>type=3D"cite">ABIs, but those will probably be =
>>two =
>>targets)

>>e type=3D"cite">>>type=3D"cite">This might let us save some =
>>unnecessary forking of *.i3 =
>>files.
>>type=3D"cite">>>type=3D"cite">The initialization here can be =
>>further =
>>streamlined.

>>quote type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">shrink SOLgnu/SOLsun from =
>>sigjmpbuf to =
>>jmpbuf
>>type=3D"cite">>>type=3D"cite">I'm not sure we use this though =
>>since we have a stack =
>>walker.

>> type=3D"cite">>>type=3D"cite">fix SPARC64_SOLARIS too to be =
>>smaller

>> type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">>>type=3D"cite">SPARC32_SOLARIS
>>blockquote>
>> type=3D"cite">jmpbuf size: =
>>48
>>type=3D"cite">>>type=3D"cite">sigjmpbuf size: =
>>76
>>type=3D"cite">>>type=3D"cite">alignment: 4 =
>>4
>>type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">>>type=3D"cite">SPARC64_SOLARIS
>>blockquote>
>> type=3D"cite">jmpbuf size: =
>>96
>>type=3D"cite">>>type=3D"cite">sigjmpbuf size: =
>>152
>>type=3D"cite">>>type=3D"cite">alignment: 8 =
>>8
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">
>>style=3D"white-space:pre">>>style=3D"white-space:pre"> >>style=3D"white-space:pre">  ??>>class=3D"Apple-tab-span" style=3D"white-space:pre">>>class=3D"Apple-tab-span" style=3D"white-space:pre">  =
>>?

=
>>
>>--Apple-Mail-78-848772270--
 		 	   		  

From jay.krell at cornell.edu  Sun May  9 01:54:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 23:54:49 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>,
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>,
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
Message-ID: <COL101-W2850411CE9F0D7659AA965E6F70@phx.gbl>


>> but on the other, we don't have a good debugger story anyway.
>
> m3gdb works well on certain platforms.


?I don't want to build m3gdb.
?It doesn't work on all platforms.
?gdb should suffice.
? Must parameters/locals really have gibberish names and can we really not
? represent the types in a manner that gdb understands?
?We need CodeView information on Windows.
At least I figured out that Debian 4.0 was part of the problem, fixed in Debian 5.0.
? (I didn't realize I was still running 4.0! I've upgraded since.)

?- Jay
 		 	   		  

From mika at async.async.caltech.edu  Sun May  9 01:55:53 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 08 May 2010 16:55:53 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W487024C8B81D4B8120C348E6F70@phx.gbl> 
References: <20100508220958.8EA242474003@birch.elegosoft.com>, ,
	<62B45315-F33E-4586-BCCE-CE57F5E307EA@cs.purdue.edu>,
	<COL101-W455DE8BD33138D220620E6E6F70@phx.gbl>, ,
	<C7985D61-0C4C-44B8-ACBE-2548725E3153@cs.purdue.edu>,
	<COL101-W94565E47A143953025584E6F70@phx.gbl>,
	<6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu>,
	<20100508234309.937D21A2095@async.async.caltech.edu>
	<COL101-W487024C8B81D4B8120C348E6F70@phx.gbl>
Message-ID: <20100508235553.70BB41A2097@async.async.caltech.edu>

Jay K writes:
>
>It's not a closed system. Modula-3 can call C can call C++ can call Modula-=
>3=2C etc.=2C and they can call raise exceptions.
>I'm not sure what the C exception story is on all platforms=2C but at least=
> on Windows there is RaiseException.
>
>Green book doesn't mention m3-libs/m3core/src/Unix=2C but it exists anyway.
>
>=A0- Jay

Well the fact that there is no specification means there's no definition
of what behavior is "correct."  I think it's up to the user of the 
primitives to ensure he's not breaking anything, if it's not defined 
in the Book.

Surely the way to deal with it is to make the user simply guarantee
that whatever C routines he calls will in fact conform with Modula-3's
parameter passing and exception behavior.  

So it would be nice to document how one goes about writing a C program
so that it conforms with (a particular implementation of) Modula-3's
conventions.  But changing the signal mask?  Maybe such a programmer
shouldn't be programming in Modula-3, not if his demands on M3 cause
things to slow down significantly for users who are writing their code
mostly in Modula-3.  (As far as I know there's no real reason to write
your code in C if you can use Modula-3, not sure about C++.)

    Mika


From rcolebur at SCIRES.COM  Sun May  9 03:14:53 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 8 May 2010 21:14:53 -0400
Subject: [M3devel] m3core broken on Usocket.c in HEAD
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C1895B4B@ATLEX02-SRV.SCIRES.LOCAL>

I am noticing that Usocket.c in m3-libs\m3core fails to compile on Windows.
This is from the HEAD branch.
Regards,
Randy

________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100508/971abbb4/attachment.html>

From peter.mckinna at gmail.com  Sun May  9 13:51:05 2010
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 9 May 2010 21:51:05 +1000
Subject: [M3devel] Compile Options
In-Reply-To: <C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
	<C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>
Message-ID: <j2t3d9e5afc1005090451x1ffbc3a1x664ce53571d300e2@mail.gmail.com>

Sorry should have mentioned AMD_64 linux.  I was trying to check if the code
generator was screwing up and every time I made a slight change the stabs
were completely different in the 2 ms files from the same module. In fact
the generated code was so completely different for just 2 lines of M3 I
found it incomprehensible. I tried to turn off the debugging to reduce the
clutter. So then I played around with some of the other compile time
switches and found some problems. This is in version 5.8.4

Regards
Peter

On Sat, May 8, 2010 at 2:55 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:

> What target platform?
>
> On 8 May 2010, at 00:22, Peter McKinna wrote:
>
> > Hey,
> >
> >   Using -c to disable library or program generation does not seem to
> work. Also how do you turn off debug symbol generation?
> > And the -O switch doesnt seem to optimise anything.
> >
> >   Is it just me or the documentation.
> >
> > Regards
> >
> > Peter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100509/7020fda3/attachment.html>

From jay.krell at cornell.edu  Sun May  9 14:44:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 9 May 2010 12:44:26 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <j2t3d9e5afc1005090451x1ffbc3a1x664ce53571d300e2@mail.gmail.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>,
	<C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>,
	<j2t3d9e5afc1005090451x1ffbc3a1x664ce53571d300e2@mail.gmail.com>
Message-ID: <COL101-W178E2932A99B8781F0FE6CE6F80@phx.gbl>


aha, good reason to disable debugging.

I think this has been broken a very long time -- the usage says debugging is the default,
and that is true..and I see no way to disable it..

Either we need like -g0 or the default should be no symbols.
??

You can also hack the config files -- remove any -g(stabs)(+).
? An ok option for your immediate purposes, if not the right general solution for everyone.


I forgot to mention in my commit comment: I did go ahead with the m3back_debug, m3back_optimize switches.
It should be you just set m3back_debug = "" in the toplevel config (or maybe with -D on the command line?) no symbols.

Also more subtly I changed optimizing from -O3 to -O2 -Wuninitialized.
Maybe should leave that alone..as I almost never use it either way.


?- Jay

________________________________
> Date: Sun, 9 May 2010 21:51:05 +1000
> From: peter.mckinna at gmail.com
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compile Options
>
> Sorry should have mentioned AMD_64 linux. I was trying to check if the code generator was screwing up and every time I made a slight change the stabs were completely different in the 2 ms files from the same module. In fact the generated code was so completely different for just 2 lines of M3 I found it incomprehensible. I tried to turn off the debugging to reduce the clutter. So then I played around with some of the other compile time switches and found some problems. This is in version 5.8.4
>
>
> Regards
> Peter
>
> On Sat, May 8, 2010 at 2:55 PM, Tony Hosking> wrote:
>
> What target platform?
>
>
>
> On 8 May 2010, at 00:22, Peter McKinna wrote:
>
>
>
>> Hey,
>
>>
>
>> Using -c to disable library or program generation does not seem to work. Also how do you turn off debug symbol generation?
>
>> And the -O switch doesnt seem to optimise anything.
>
>>
>
>> Is it just me or the documentation.
>
>>
>
>> Regards
>
>>
>
>> Peter
>
>
>
>
 		 	   		  

From wagner at elegosoft.com  Mon May 10 10:26:41 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 10 May 2010 10:26:41 +0200
Subject: [M3devel] builds on release branch broken
Message-ID: <20100510102641.ab1etdvcgs4s0oos@mail.elegosoft.com>

I just noticed several build failures on the release branch.
One seems to be caused by this:

=== package m3-sys/m3middle ===
  +++ cm3 -build  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'  
-DCM3_LAST_CHANGED='2010-04-11'  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'  
-DCM3LASTCHANGED='2010-04-11' $RARGS  && cm3 -ship $RARGS  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'  
-DCM3_LAST_CHANGED='2010-04-11'  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'  
-DCM3LASTCHANGED='2010-04-11'  +++
gcc: ../src/POSIX/CoffTime.c: No such file or directory
gcc: No input files specified
   compile_c => 1
C compiler failed compiling: ../src/POSIX/CoffTime.c
gcc: ../src/POSIX/CoffTime.c: No such file or directory
gcc: No input files specified
   compile_c => 1
C compiler failed compiling: ../src/POSIX/CoffTime.c
retry build after cleaning

See http://hudson.modula3.com:8080/job/cm3-build-AMD64_FREEBSD/104/, too.

One of these commits seems to be the culprit:

Changes

    1. move _DARWIN_FEATURE_64_ONLY_BIT_INODE earlier, so that it will work
       (This only affects ARM_DARWIN I believe, and maybe not even  
it.) (detail)
    2. copy from head so it compiles (detail)
    3. copy from head, so that release can be built by "upgrading" from head
       (head m3core has cut down/removed Utime for portability, and it
       was used here)) (detail)
    4. whitespace only (detail)

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  Mon May 10 10:38:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 10 May 2010 08:38:44 +0000
Subject: [M3devel] builds on release branch broken
In-Reply-To: <20100510102641.ab1etdvcgs4s0oos@mail.elegosoft.com>
References: <20100510102641.ab1etdvcgs4s0oos@mail.elegosoft.com>
Message-ID: <COL101-W7420AE3AB05362E9C432FE6F90@phx.gbl>


understood, I'll fix shortly

?- Jay


----------------------------------------
> Date: Mon, 10 May 2010 10:26:41 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] builds on release branch broken
>
> I just noticed several build failures on the release branch.
> One seems to be caused by this:
>
> === package m3-sys/m3middle ===
> +++ cm3 -build
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'
> -DCM3_LAST_CHANGED='2010-04-11'
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'
> -DCM3LASTCHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'
> -DCM3_LAST_CHANGED='2010-04-11'
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'
> -DCM3LASTCHANGED='2010-04-11' +++
> gcc: ../src/POSIX/CoffTime.c: No such file or directory
> gcc: No input files specified
> compile_c => 1
> C compiler failed compiling: ../src/POSIX/CoffTime.c
> gcc: ../src/POSIX/CoffTime.c: No such file or directory
> gcc: No input files specified
> compile_c => 1
> C compiler failed compiling: ../src/POSIX/CoffTime.c
> retry build after cleaning
>
> See http://hudson.modula3.com:8080/job/cm3-build-AMD64_FREEBSD/104/, too.
>
> One of these commits seems to be the culprit:
>
> Changes
>
> 1. move _DARWIN_FEATURE_64_ONLY_BIT_INODE earlier, so that it will work
> (This only affects ARM_DARWIN I believe, and maybe not even
> it.) (detail)
> 2. copy from head so it compiles (detail)
> 3. copy from head, so that release can be built by "upgrading" from head
> (head m3core has cut down/removed Utime for portability, and it
> was used here)) (detail)
> 4. whitespace only (detail)
>
> 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  Mon May 10 11:37:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 10 May 2010 09:37:21 +0000
Subject: [M3devel] program vs. Program
Message-ID: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>


Despite the length of this email, I don't think this is a big deal..


With the "origin/runpath" changes from a while ago, "program" "doesn't work", unless build_standalone.
At least on most systems. That is, you can't run the binary from its shipped location, in pkg.


We should consider: 
?- make program imply build_standalone? 
?- never ship "program" -- not runable within the package store? 
?- drop in wrapper .sh files that set/append LD_LIBRARY_PATH? 
?- maybe the scheme I alluded to, which I'm pretty sure libtool implements sometimes, where you use full paths on the initial link, an then "ship/install" relink first, either with new full paths or with $ORIGIN.


An exception would be, like, how gcc uses libexec/cc1.
?If something in bin calls out to something in pkg, and either the file in pkg is build_standalone, or, well $ORIGIN sometimes
?is relative to the executable -- like on Mac OSX 10.4 with @executable_path, but this is probably too rare to consider.
And even if we have "private" executables in "pkg", build_standalone is still wasteful.


So we'd want to look through stuff like:


jbook2:cm3 jay$ grep ^program `find . | grep /m3makefile$` | grep -v examples | grep -v test
./caltech-parser/hack/src/m3makefile:program("dummy")
./doc/tutorial/ui/script/m3makefile:program ("script")
./m3-comm/tapi/src/m3makefile:program ("foo2")
./m3-db/db/demo/m3makefile:program("demo")
./m3-db/db/src/postgresql/demo/m3makefile:program("demo")
./m3-db/stable/example/src/m3makefile:program("example")
./m3-demo/sharedboard/boardclient/src/m3makefile:program ("boardclient")
./m3-demo/sharedboard/boardserver/src/m3makefile:program ("boardserver")
./m3-demo/sharedboard/calendar/src/m3makefile:program ("calendar")
./m3-libs/digraph/src/m3makefile:program(DiGraphTest)
./m3-libs/digraph/src/m3makefile:program(TopSortTest)
./m3-libs/synthesizer/example/chirp/src/m3makefile:program("chirp")
./m3-libs/synthesizer/example/echo/src/m3makefile:program("echo")
./m3-libs/synthesizer/example/entchen/src/m3makefile:program("entchen")
./m3-libs/synthesizer/example/filter/src/m3makefile:program("filter")
./m3-libs/synthesizer/example/inout/src/m3makefile:program("inout")
./m3-libs/synthesizer/example/oscillator/src/m3makefile:program("oscillator")
./m3-libs/synthesizer/example/plot/src/m3makefile:program("plot")
./m3-libs/synthesizer/example/rueckwaerts/src/m3makefile:program("rueckwaerts")
./m3-libs/synthesizer/example/sirene/src/m3makefile:program("sirene")
./m3-libs/synthesizer/example/stereo/src/m3makefile:program("stereo")
./m3-libs/synthesizer/example/stream/src/m3makefile:program("stream")
./m3-libs/wellfett/example/src/m3makefile:program("example")
./m3-pkgtools/pkgfprint/src/m3makefile:program("pkgfp")
./m3-pkgtools/pkgq/src/m3makefile:program("pkgq")
./m3-pkgtools/pkgsrv/src/m3makefile:program("packageserver")
./m3-pkgtools/pkgtool/src/m3makefile:program("packagetool")
./m3-sys/cm3/src/m3makefile:program ("cm3")
./m3-sys/cminstall/src/m3makefile:program ("cminstall")
./m3-sys/dll2lib/src/m3makefile:program ("dll2lib")
./m3-sys/libdump/src/m3makefile:program ("libdump")
./m3-sys/m3cgcat/src/m3makefile:program ("m3cgcat")
./m3-sys/m3cggen/src/m3makefile:program ("m3cggen")
./m3-sys/m3staloneback/src/m3makefile:program ("m3back")
./m3-tools/cmpfp/src/m3makefile:program ("cmpfp")
./m3-tools/cvsup/cvpasswd/src/m3makefile:program("cvpasswd")
./m3-tools/macapi/src/m3makefile:program("macapi")
./m3-ui/juno-2/juno-app/pkl-fonts/src/m3makefile:program??? ??? ("PklFonts")
./m3-ui/juno-2/juno-machine/linear/src/m3makefile:program("LinearTest")
./m3-ui/juno-2/juno-machine/nonlinear/src/m3makefile:program??? ??? ("NonLinearTest")
./m3-ui/juno-2/juno-machine/runtime/src/m3makefile:program??? ??? ("RuntimeTest")
./m3-ui/juno-2/juno-machine/solve/src/m3makefile:program??? ??? ("SolveTest")


At a quick glance, a lot can be ignored. Anything without quotes doesn't curently build.
m3-pkgtools doesn't currently build.
cm3 and cminstall are "special" -- and still, we shouldn't bother putting them in pkg.
m3back is never used; m3ccgen is standalone and rarely used
libdump I think is unused; dll2lib is unused.
This doesn't check if things are build_standalone, e.g. PklFonts.


?- Jay


 		 	   		  

From hosking at cs.purdue.edu  Mon May 10 15:42:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 10 May 2010 09:42:12 -0400
Subject: [M3devel] program vs. Program
In-Reply-To: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>
References: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>
Message-ID: <358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>

program is not supposed to ship anything, right?

Only Program should do that.

On 10 May 2010, at 05:37, Jay K wrote:

> 
> Despite the length of this email, I don't think this is a big deal..
> 
> 
> With the "origin/runpath" changes from a while ago, "program" "doesn't work", unless build_standalone.
> At least on most systems. That is, you can't run the binary from its shipped location, in pkg.
> 
> 
> We should consider: 
>  - make program imply build_standalone? 
>  - never ship "program" -- not runable within the package store  
>  - drop in wrapper .sh files that set/append LD_LIBRARY_PATH? 
>  - maybe the scheme I alluded to, which I'm pretty sure libtool implements sometimes, where you use full paths on the initial link, an then "ship/install" relink first, either with new full paths or with $ORIGIN.
> 
> 
> An exception would be, like, how gcc uses libexec/cc1.
>  If something in bin calls out to something in pkg, and either the file in pkg is build_standalone, or, well $ORIGIN sometimes
>  is relative to the executable -- like on Mac OSX 10.4 with @executable_path, but this is probably too rare to consider.
> And even if we have "private" executables in "pkg", build_standalone is still wasteful.
> 
> 
> So we'd want to look through stuff like:
> 
> 
> jbook2:cm3 jay$ grep ^program `find . | grep /m3makefile$` | grep -v examples | grep -v test
> ./caltech-parser/hack/src/m3makefile:program("dummy")
> ./doc/tutorial/ui/script/m3makefile:program ("script")
> ./m3-comm/tapi/src/m3makefile:program ("foo2")
> ./m3-db/db/demo/m3makefile:program("demo")
> ./m3-db/db/src/postgresql/demo/m3makefile:program("demo")
> ./m3-db/stable/example/src/m3makefile:program("example")
> ./m3-demo/sharedboard/boardclient/src/m3makefile:program ("boardclient")
> ./m3-demo/sharedboard/boardserver/src/m3makefile:program ("boardserver")
> ./m3-demo/sharedboard/calendar/src/m3makefile:program ("calendar")
> ./m3-libs/digraph/src/m3makefile:program(DiGraphTest)
> ./m3-libs/digraph/src/m3makefile:program(TopSortTest)
> ./m3-libs/synthesizer/example/chirp/src/m3makefile:program("chirp")
> ./m3-libs/synthesizer/example/echo/src/m3makefile:program("echo")
> ./m3-libs/synthesizer/example/entchen/src/m3makefile:program("entchen")
> ./m3-libs/synthesizer/example/filter/src/m3makefile:program("filter")
> ./m3-libs/synthesizer/example/inout/src/m3makefile:program("inout")
> ./m3-libs/synthesizer/example/oscillator/src/m3makefile:program("oscillator")
> ./m3-libs/synthesizer/example/plot/src/m3makefile:program("plot")
> ./m3-libs/synthesizer/example/rueckwaerts/src/m3makefile:program("rueckwaerts")
> ./m3-libs/synthesizer/example/sirene/src/m3makefile:program("sirene")
> ./m3-libs/synthesizer/example/stereo/src/m3makefile:program("stereo")
> ./m3-libs/synthesizer/example/stream/src/m3makefile:program("stream")
> ./m3-libs/wellfett/example/src/m3makefile:program("example")
> ./m3-pkgtools/pkgfprint/src/m3makefile:program("pkgfp")
> ./m3-pkgtools/pkgq/src/m3makefile:program("pkgq")
> ./m3-pkgtools/pkgsrv/src/m3makefile:program("packageserver")
> ./m3-pkgtools/pkgtool/src/m3makefile:program("packagetool")
> ./m3-sys/cm3/src/m3makefile:program ("cm3")
> ./m3-sys/cminstall/src/m3makefile:program ("cminstall")
> ./m3-sys/dll2lib/src/m3makefile:program ("dll2lib")
> ./m3-sys/libdump/src/m3makefile:program ("libdump")
> ./m3-sys/m3cgcat/src/m3makefile:program ("m3cgcat")
> ./m3-sys/m3cggen/src/m3makefile:program ("m3cggen")
> ./m3-sys/m3staloneback/src/m3makefile:program ("m3back")
> ./m3-tools/cmpfp/src/m3makefile:program ("cmpfp")
> ./m3-tools/cvsup/cvpasswd/src/m3makefile:program("cvpasswd")
> ./m3-tools/macapi/src/m3makefile:program("macapi")
> ./m3-ui/juno-2/juno-app/pkl-fonts/src/m3makefile:program        ("PklFonts")
> ./m3-ui/juno-2/juno-machine/linear/src/m3makefile:program("LinearTest")
> ./m3-ui/juno-2/juno-machine/nonlinear/src/m3makefile:program        ("NonLinearTest")
> ./m3-ui/juno-2/juno-machine/runtime/src/m3makefile:program        ("RuntimeTest")
> ./m3-ui/juno-2/juno-machine/solve/src/m3makefile:program        ("SolveTest")
> 
> 
> At a quick glance, a lot can be ignored. Anything without quotes doesn't curently build.
> m3-pkgtools doesn't currently build.
> cm3 and cminstall are "special" -- and still, we shouldn't bother putting them in pkg.
> m3back is never used; m3ccgen is standalone and rarely used
> libdump I think is unused; dll2lib is unused.
> This doesn't check if things are build_standalone, e.g. PklFonts.
> 
> 
>  - Jay
> 
> 
> 		 	   		  



From wagner at elegosoft.com  Mon May 10 17:40:15 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 10 May 2010 17:40:15 +0200
Subject: [M3devel] program vs. Program
In-Reply-To: <358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>
References: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>
	<358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>
Message-ID: <20100510174015.0s21r39i68ck80sc@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> program is not supposed to ship anything, right?

program ships to the /pkg/TARGET directory, while
Program shipts to /bin.

> Only Program should do that.
>
> On 10 May 2010, at 05:37, Jay K wrote:
>
>> Despite the length of this email, I don't think this is a big deal..
>>
>> With the "origin/runpath" changes from a while ago, "program"   
>> "doesn't work", unless build_standalone.
>> At least on most systems. That is, you can't run the binary from   
>> its shipped location, in pkg.
>>
>> We should consider:
>>  - make program imply build_standalone?

Probably simplest solution, but not really what I would expect.

>>  - never ship "program" -- not runable within the package store

Would be a non-compatible change.

>>  - drop in wrapper .sh files that set/append LD_LIBRARY_PATH?

Strange.

>>  - maybe the scheme I alluded to, which I'm pretty sure libtool   
>> implements sometimes, where you use full paths on the initial link,  
>>  an then "ship/install" relink first, either with new full paths or  
>>  with $ORIGIN.

Why not use the correct paths via $ORIGIN? For program they are
of course different than for Program. Too difficult?

Not yet sure what we should do,

Olaf


>>
>>
>> An exception would be, like, how gcc uses libexec/cc1.
>>  If something in bin calls out to something in pkg, and either the   
>> file in pkg is build_standalone, or, well $ORIGIN sometimes
>>  is relative to the executable -- like on Mac OSX 10.4 with   
>> @executable_path, but this is probably too rare to consider.
>> And even if we have "private" executables in "pkg",   
>> build_standalone is still wasteful.
>>
>>
>> So we'd want to look through stuff like:
>>
>>
>> jbook2:cm3 jay$ grep ^program `find . | grep /m3makefile$` | grep   
>> -v examples | grep -v test
>> ./caltech-parser/hack/src/m3makefile:program("dummy")
>> ./doc/tutorial/ui/script/m3makefile:program ("script")
>> ./m3-comm/tapi/src/m3makefile:program ("foo2")
>> ./m3-db/db/demo/m3makefile:program("demo")
>> ./m3-db/db/src/postgresql/demo/m3makefile:program("demo")
>> ./m3-db/stable/example/src/m3makefile:program("example")
>> ./m3-demo/sharedboard/boardclient/src/m3makefile:program ("boardclient")
>> ./m3-demo/sharedboard/boardserver/src/m3makefile:program ("boardserver")
>> ./m3-demo/sharedboard/calendar/src/m3makefile:program ("calendar")
>> ./m3-libs/digraph/src/m3makefile:program(DiGraphTest)
>> ./m3-libs/digraph/src/m3makefile:program(TopSortTest)
>> ./m3-libs/synthesizer/example/chirp/src/m3makefile:program("chirp")
>> ./m3-libs/synthesizer/example/echo/src/m3makefile:program("echo")
>> ./m3-libs/synthesizer/example/entchen/src/m3makefile:program("entchen")
>> ./m3-libs/synthesizer/example/filter/src/m3makefile:program("filter")
>> ./m3-libs/synthesizer/example/inout/src/m3makefile:program("inout")
>> ./m3-libs/synthesizer/example/oscillator/src/m3makefile:program("oscillator")
>> ./m3-libs/synthesizer/example/plot/src/m3makefile:program("plot")
>> ./m3-libs/synthesizer/example/rueckwaerts/src/m3makefile:program("rueckwaerts")
>> ./m3-libs/synthesizer/example/sirene/src/m3makefile:program("sirene")
>> ./m3-libs/synthesizer/example/stereo/src/m3makefile:program("stereo")
>> ./m3-libs/synthesizer/example/stream/src/m3makefile:program("stream")
>> ./m3-libs/wellfett/example/src/m3makefile:program("example")
>> ./m3-pkgtools/pkgfprint/src/m3makefile:program("pkgfp")
>> ./m3-pkgtools/pkgq/src/m3makefile:program("pkgq")
>> ./m3-pkgtools/pkgsrv/src/m3makefile:program("packageserver")
>> ./m3-pkgtools/pkgtool/src/m3makefile:program("packagetool")
>> ./m3-sys/cm3/src/m3makefile:program ("cm3")
>> ./m3-sys/cminstall/src/m3makefile:program ("cminstall")
>> ./m3-sys/dll2lib/src/m3makefile:program ("dll2lib")
>> ./m3-sys/libdump/src/m3makefile:program ("libdump")
>> ./m3-sys/m3cgcat/src/m3makefile:program ("m3cgcat")
>> ./m3-sys/m3cggen/src/m3makefile:program ("m3cggen")
>> ./m3-sys/m3staloneback/src/m3makefile:program ("m3back")
>> ./m3-tools/cmpfp/src/m3makefile:program ("cmpfp")
>> ./m3-tools/cvsup/cvpasswd/src/m3makefile:program("cvpasswd")
>> ./m3-tools/macapi/src/m3makefile:program("macapi")
>> ./m3-ui/juno-2/juno-app/pkl-fonts/src/m3makefile:program        ("PklFonts")
>> ./m3-ui/juno-2/juno-machine/linear/src/m3makefile:program("LinearTest")
>> ./m3-ui/juno-2/juno-machine/nonlinear/src/m3makefile:program         
>>  ("NonLinearTest")
>> ./m3-ui/juno-2/juno-machine/runtime/src/m3makefile:program          
>> ("RuntimeTest")
>> ./m3-ui/juno-2/juno-machine/solve/src/m3makefile:program          
>> ("SolveTest")
>>
>>
>> At a quick glance, a lot can be ignored. Anything without quotes   
>> doesn't curently build.
>> m3-pkgtools doesn't currently build.
>> cm3 and cminstall are "special" -- and still, we shouldn't bother   
>> putting them in pkg.
>> m3back is never used; m3ccgen is standalone and rarely used
>> libdump I think is unused; dll2lib is unused.
>> This doesn't check if things are build_standalone, e.g. PklFonts.
>>
>>
>>  - Jay
>>
>>
>>
>
>



-- 
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 rcolebur at SCIRES.COM  Mon May 10 21:19:39 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 10 May 2010 15:19:39 -0400
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20100509063527.854BC2474003@birch.elegosoft.com>
References: <20100509063527.854BC2474003@birch.elegosoft.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C1895CB6@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

I agree with some of your sentiments about the ugliness of the POSIX GUI, e.g. C & G buttons for close and grow, but I again want to point out that the "Win32" GUI is not ideal either.

Please recall that the changes made in the Win32 side were to make the Trestle/FormsVBT GUI appear more like Windows NT GUI at the time, but these are only approximations and it is not identical.  Plus, the Windows GUI continues to evolve, so the look and feel is now even further apart from the Windows Aero interface, than in 1995 when my company paid CMass to make the Win32 NT mods.  I haven't used X-Windows in a while, so not sure how far apart Trestle on X is from just X.

The other aspect that needs to be considered is that if the look/feel of the GUI changes, someone needs to update all the Trestle/FormsVBT documentation to match.  This may also create a cascade of documentation edits for any user programs/systems built and documented using the prior look and feel.

Note that the operation of scroll bars as documented under Trestle/FormsVBT are radically different from Microsoft Windows.  The current Win32 scroll bar implementation is closer to MS Windows, but it is still different, and it is not documented in Trestle/FormsVBT.  (I have a write-up on this I can provide.)

Depending on the needs/desires of the M3 community, there may be a need to maintain some runtime switch or compile time option to switch between the old style look and feel and any new style that is implemented.

Perhaps we should have a discussion in the m3devel forum to see how folks want to proceed before making any radical changes in the GUI look and feel.

Regards,
Randy

-----Original Message-----
From: Jay Krell [mailto:jkrell at elego.de]
Sent: Sunday, May 09, 2010 4:35 AM
To: m3commit at elegosoft.com
Subject: [M3commit] CVS Update: cm3

CVSROOT:        /usr/cvs
Changes by:     jkrell at birch.   10/05/09 08:35:27

Modified files:
        cm3/m3-ui/vbtkit/src/lego/: ZChassisVBT.m3 m3makefile
        cm3/m3-ui/vbtkit/src/lego/POSIX/: m3makefile
        cm3/m3-ui/vbtkit/src/lego/WIN32/: m3makefile
Removed files:
        cm3/m3-ui/vbtkit/src/lego/POSIX/: ZChassisVBT.m3
        cm3/m3-ui/vbtkit/src/lego/WIN32/: ZChassisVBT.m3

Log message:
        unfork ZChassisVBT.m3

        instead of copying 140 lines and changing a few, when
        both variations are portable, you can test
        Compiler.ThisOS = Compiler.OS.POSIX or Compiler.OS.WIN32
        and just have both variations.

        Alternately, make a /smaller/ interface and /smaller/ implementation
        that just contains the changed functions/lines

        The larger ScrollerVBTClass.m3 file received more churn so
        merging might not be viable/worthwhile.

        Besides, the Posix gui is terrible here, G for grow, C for close,
        we should probably just use the Win32 gui everywhere.


CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s).  This email may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.


From jay.krell at cornell.edu  Tue May 11 00:17:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 10 May 2010 22:17:05 +0000
Subject: [M3devel] program vs. Program
In-Reply-To: <20100510174015.0s21r39i68ck80sc@mail.elegosoft.com>
References: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>,
	<358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>,
	<20100510174015.0s21r39i68ck80sc@mail.elegosoft.com>
Message-ID: <COL101-W16DE2F184010AA8A1AFF44E6F90@phx.gbl>


>>> - never ship "program" -- not runable within the package store
>
> Would be a non-compatible change.
 
 
It's already non-compatible imho, except if LD_LIBRARY_PATH is used.
 

>>> - drop in wrapper .sh files that set/append LD_LIBRARY_PATH?
>
> Strange.
 
 
I believe this is a practise in the wider world, though not
very common or considered very good.
 
Actually some things I read say LD_LIBRARY_PATH is meant for
running stuff before install. Just don't abuse it and
use it after install. (it is the old link below though,
I should read more)
 

> Why not use the correct paths via $ORIGIN? For program they are
> of course different than for Program. Too difficult?
 
 
Ah, like ../../lib? To go our of pkg/target and over to lib?
Yeah, that is possible.
I had that in, but such "far up" relative paths worry me.
If the program is moved around to a shallower structure
it could accidentally reach into unrelated stuff.
 
 
It is mitigated by using:
  $ORIGIN:$ORIGIN/../lib:$ORIGIN/../../lib
 
 
so at least you find closer stuff first.
Maybe we can put just the last element in for program.
 
 
> http://xahlee.org/UnixResource_dir/_/ldpath.html
 
 
This is an old link, mostly predates $ORIGIN,
but does bring up the possibility of
linking or editing paths at install time.
 
 
Controversial suggestion: use autoconf/libtool.
It probably handles this stuff already.
 
 
 - Jay
  		 	   		  

From wagner at elegosoft.com  Wed May 12 08:51:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 12 May 2010 08:51:24 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>,
	<20100511090214.5bsr2f24o4oscg88@mail.elegosof, t, .com>, <F6
	43890B-0 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>
Message-ID: <20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>

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

>> It's nothing like just shifting the jobs from Jay's machine to opencsw.
>> I've already made half a dozen changes for a simple compile job.
>
>
> Hm. Maybe I should try installing Solaris 2.9 on my machine? Or a   
> separate machine first?
> I would like to offload to Dago if possible.

I understand that.

I can now check out with CVS from the command line, both via the
pserver proxy and a forwarded port via ssh, but still no luck with
Hudson itself. The failure message stays the same
(see http://hudson.modula3.com:8080/view/SOLsun/job/dummy/7/console).

Ideas what's going on are welcome.

But it's not just CVS. The regression test scripts check for
explicit ssh reachability of birch.elegosoft.com; we need scp
or rsync to upload archives, and wget or curl to download.
I'm sure the list will get even longer if we inspect the existing
jobs.

> I had tried to install Solaris 2.8 and/or 2.9 at some point but hit   
> some difficulty.
> 2.10 I've now installed multiple times, it is fairly easy.
>
> So..remember..I don't have any fixed IP addresses at all.
> I use free dynamic DNS and port forwarding.
>   Stuff I didn't know about but Olaf pointed me toward and I'm   
> pleased with it. :)
> Is that viable here?
>   You wouldn't need dynamic DNS, just port forwarding. As I understand.
> Like, port 222 on login goes to 22 on current9s, stuff like that.

I doubt that opencsw will change their setup for m3.

I'm sure we can work around every little or big problem that comes
up, but I simply haven't got the time for it.

I'd be happy if anybody else tries to port all the SOLsun jobs
from http://hudson.modula3.com:8080/view/SOLsun/
(copy to another name and then adapt) to run on
http://hudson.modula3.com:8080/computer/opencsw_current9s/.

My simple test job currently is in
http://hudson.modula3.com:8080/view/SOLsun/job/dummy/

If nobody else volunteers, I'll try to work on it now and then, but
cannot promise any deadline.

Thanks for all your support,

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 May 12 09:43:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 12 May 2010 07:43:35 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4oscg88@mail.el egosof,
	t, .com>, <F6,43890B-0
	0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>
Message-ID: <COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>


> test scripts check for explicit ssh reachability of birch.elegosoft.com
 
 
I put that in.
I found the stuff too hard to use and would try to make it easier as I figured it out.
 
 
 
Well.. for now let's just leave Hudson on my machine asis.
  Maybe Tony can provide a machine?
 
 
 
So..a general dilemna is how to give Dago something for him giving us something.
And how much is enough on either side?
Don't want to take and not give back, or whatnot.
 
 
 
I386_SOLARIS, AMD64_SOLARIS are now in good shape.
See http://www.modula3.com/cm3/uploaded-archives/index.html.
 
 
 
System builds itself.
  The whole thing on x86/2.10. Up to opengl on x86/2.9.
    I think I'll just do an existance check on 2.9 and stuff built there will just omit it.
 
  I haven't tested the X apps yet.
 
  I haven't tried Sparc32/64 yet on 2.8/2.9, but they could very well work ok.
     2.8 would have a problem with user threads, but I know how to fix it.
     (Dago is ok dropping 2.8 anyway, and user threads also don't really matter).
 
 
How much value is there to an occasional manual build, vs. better automation?
  With or without running the tests?
  Like, not hudson?
 
 
At some point I'll probably setup Solaris/x86.
  I already have, multiple times, just haven't configured it to my liking and kept it up and running.
  But I'd like to offload some power/heat/environmental-responsibility maybe.
  Maybe trade for other OSes. :)
  Also distribute the responsibility anyway. You don't want it all depending on my network connectivity, even if it was good. :)
 
 
I may have another option for Solaris. I'll check.
 
 
I can think of somewhat rude suggestions, like:
   Commit access shall be limited unless commiter provides Hudson resources. :)
   Of any sort or non-zero quantity -- don't make things too hard.
   Heck -- surely Linux/x86 is among the easiest for anyone to take. :)
   Then again, I'm not a manager, maybe I shouldn't try to think of ways to motivate people. :)
 
 
Also maybe login is usable at least for Solaris 2.10 sparc stuff?
Or is that an abuse?
 
 
 
Thanks,
 - Jay


----------------------------------------
> Date: Wed, 12 May 2010 08:51:24 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; trygvis at opencsw.org; dam at baltic-online.de
> Subject: Re: [M3devel] OpenCSW build farm access
>
> Quoting Jay K :
>
>>> It's nothing like just shifting the jobs from Jay's machine to opencsw.
>>> I've already made half a dozen changes for a simple compile job.
>>
>>
>> Hm. Maybe I should try installing Solaris 2.9 on my machine? Or a
>> separate machine first?
>> I would like to offload to Dago if possible.
>
> I understand that.
>
> I can now check out with CVS from the command line, both via the
> pserver proxy and a forwarded port via ssh, but still no luck with
> Hudson itself. The failure message stays the same
> (see http://hudson.modula3.com:8080/view/SOLsun/job/dummy/7/console).
>
> Ideas what's going on are welcome.
>
> But it's not just CVS. The regression test scripts check for
> explicit ssh reachability of birch.elegosoft.com; we need scp
> or rsync to upload archives, and wget or curl to download.
> I'm sure the list will get even longer if we inspect the existing
> jobs.
>
>> I had tried to install Solaris 2.8 and/or 2.9 at some point but hit
>> some difficulty.
>> 2.10 I've now installed multiple times, it is fairly easy.
>>
>> So..remember..I don't have any fixed IP addresses at all.
>> I use free dynamic DNS and port forwarding.
>> Stuff I didn't know about but Olaf pointed me toward and I'm
>> pleased with it. :)
>> Is that viable here?
>> You wouldn't need dynamic DNS, just port forwarding. As I understand.
>> Like, port 222 on login goes to 22 on current9s, stuff like that.
>
> I doubt that opencsw will change their setup for m3.
>
> I'm sure we can work around every little or big problem that comes
> up, but I simply haven't got the time for it.
>
> I'd be happy if anybody else tries to port all the SOLsun jobs
> from http://hudson.modula3.com:8080/view/SOLsun/
> (copy to another name and then adapt) to run on
> http://hudson.modula3.com:8080/computer/opencsw_current9s/.
>
> My simple test job currently is in
> http://hudson.modula3.com:8080/view/SOLsun/job/dummy/
>
> If nobody else volunteers, I'll try to work on it now and then, but
> cannot promise any deadline.
>
> Thanks for all your support,
>
> 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 May 12 11:39:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 12 May 2010 09:39:22 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof
	, t, .com>, <F6,43890B-0
	0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
Message-ID: <COL101-W266A3DC1739A617839710BE6FB0@phx.gbl>


Just to clarify: "leave the stuff on my machine for now" is more like
"I'm not pulling the plug, take your time with Dago"
and less like "give up on Dago".

I think the Hudson init script written in Groovy be the place
to fix $PATH, to find cvs.
Give me a bit..

?> another source for Solaris cycles

Like, someone who
?- has an easier network topology
?- no Solaris 2.9 desire/agenda, who we therefore won't disappoint
??? if we don't get 2.9 working

so we don't "steal" from Dago.
(Yes, I realize I'm being wishy-washy here..)

I agree though if you already have people using Hudson...

Give me a bit on the path/cvs thing.

And I have multiple options for x86 2.9 OpenGL.

?- Jay

----------------------------------------
> CC: wagner at elegosoft.com; m3devel at elegosoft.com; trygvis at opencsw.org
> From: dam at baltic-online.de
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] OpenCSW build farm access
> Date: Wed, 12 May 2010 11:05:37 +0200
>
> Hi,
>
> Am 12.05.2010 um 09:43 schrieb Jay K:
>> Well.. for now let's just leave Hudson on my machine asis.
>> Maybe Tony can provide a machine?
>
> I'm pretty sure we can work this out. Other projects are using
> the farm also with Hudson, so it should be quite possible in the
> current configuration.
>
>> So..a general dilemna is how to give Dago something for him giving
>> us something.
>> And how much is enough on either side?
>> Don't want to take and not give back, or whatnot.
>
> Just provide cvsup for Solaris 9 sparc/x86 and I am happy :-)
> Additionally,
> a goal of providing the buildfarm is to aid upstream projects in
> ensuring
> Solaris compatibility. As you obviously do that it is perfectly ok.
>
>> I386_SOLARIS, AMD64_SOLARIS are now in good shape.
>> See http://www.modula3.com/cm3/uploaded-archives/index.html.
>
> Cool.
>
>> System builds itself.
>> The whole thing on x86/2.10. Up to opengl on x86/2.9.
>> I think I'll just do an existance check on 2.9 and stuff built
>> there will just omit it.
>>
>> I haven't tested the X apps yet.
>>
>> I haven't tried Sparc32/64 yet on 2.8/2.9, but they could very well
>> work ok.
>> 2.8 would have a problem with user threads, but I know how to
>> fix it.
>> (Dago is ok dropping 2.8 anyway, and user threads also don't
>> really matter).
>
> Yes.
>
>> How much value is there to an occasional manual build, vs. better
>> automation?
>> With or without running the tests?
>> Like, not hudson?
>>
>> At some point I'll probably setup Solaris/x86.
>> I already have, multiple times, just haven't configured it to my
>> liking and kept it up and running.
>> But I'd like to offload some power/heat/environmental-
>> responsibility maybe.
>> Maybe trade for other OSes. :)
>> Also distribute the responsibility anyway. You don't want it all
>> depending on my network connectivity, even if it was good. :)
>>
>> I may have another option for Solaris. I'll check.
>
> I do feel offended ;-)
>
>> I can think of somewhat rude suggestions, like:
>> Commit access shall be limited unless commiter provides Hudson
>> resources. :)
>> Of any sort or non-zero quantity -- don't make things too hard.
>> Heck -- surely Linux/x86 is among the easiest for anyone to take. :)
>> Then again, I'm not a manager, maybe I shouldn't try to think of
>> ways to motivate people. :)
>>
>> Also maybe login is usable at least for Solaris 2.10 sparc stuff?
>> Or is that an abuse?
>
> It is not abuse, but there is no compiler there.
>
>
> Best regards
>
> -- Dago
>
 		 	   		  

From jay.krell at cornell.edu  Wed May 12 14:29:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 12 May 2010 12:29:28 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof ,, t, .com>,
	<F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
Message-ID: <COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>


Olaf, I have some leads:


1)

http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds#Distributedbuilds-Example%3AConfigurationonUnix

# /var/hudson/bin/launch-slave is a shell script that Hudson uses to execute jobs remotely. This shell script sets up PATH and a few other things before launching slave.jar. Below is a very simple example script.

#!/bin/bash

JAVA_HOME=/opt/SUN/jdk1.6.0_04
PATH=$PATH:$JAVA_HOME/bin
export PATH
java -jar /var/hudson/bin/slave.jar

On master or slave or ??

2)
You can modify $PATH across all nodes:
http://www.modula3.com:8080/configure
Global Properties: Environment variables
This is yucky but appears easy and would work.

3)
You can specify CVS executable there.
Maybe ~/cvs or $HOME/cvs ??????
Which we'd setup appropriately.


4)
Hudson initialization script.
http://wiki.hudson-ci.org/display/HUDSON/Post-initialization+script
$HUDSON_HOME/init.groovy
I'm not sure this runs on slave or master.
I'd want to remove :/opt/csw/bin:, /opt/csw/bin:
from start, :/opt/csw/bin from end, and then insert /opt/csw/bin
somewhere, like start. That's too much Groovy for me to write,
and get working within Hudson..there is System.getenv, but
I don't see how to set the variables.


5)
You can set "tool locations".
I can't find elaboration on what that means.
Maybe
tool=cvs
location=/opt/csw/bin/cvs
?

6)
There is some mention of "PATH+".
I tried that. Didn't work.

7)
http://hudson.361315.n4.nabble.com/Slave-environment-and-Java-path-issues-td383751.html#a383752

Thanks.? You correct that I didn't understand the difference when using a non-interactive shell.
In the end I solved the problem by putting together a simple launch-slave script which sets the environment I need:

#!/bin/bash

export JAVA_HOME=/usr/lib/java 
...


8)
http://hudson.361315.n4.nabble.com/slave-s-PATH-change-not-picked-up-td1558100.html#a1559051

You were right.? The ssh itself did not load the correct PATH (I
couldn't see it via putty).? It turns out ssh does not read
/etc/profile, but it does read user's .bashrc.? Go figure...


Maybe I'll fiddle with the Hudson keys or my old key and poke around more...


?- Jay 		 	   		  

From wagner at elegosoft.com  Wed May 12 16:09:37 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 12 May 2010 16:09:37 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof ,, t, .com>,
	<F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
Message-ID: <20100512160937.5kq1fothc44c4sck@mail.elegosoft.com>

Hi Jay,

thanks for your suggestions.

I'll try to get it working tomorrow. One of them should do :-)

Olaf

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

>
> Olaf, I have some leads:
>
>
> 1)
>
> http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds#Distributedbuilds-Example%3AConfigurationonUnix
>
> # /var/hudson/bin/launch-slave is a shell script that Hudson uses to  
>  execute jobs remotely. This shell script sets up PATH and a few   
> other things before launching slave.jar. Below is a very simple   
> example script.
>
> #!/bin/bash
>
> JAVA_HOME=/opt/SUN/jdk1.6.0_04
> PATH=$PATH:$JAVA_HOME/bin
> export PATH
> java -jar /var/hudson/bin/slave.jar
>
> On master or slave or ??
>
> 2)
> You can modify $PATH across all nodes:
> http://www.modula3.com:8080/configure
> Global Properties: Environment variables
> This is yucky but appears easy and would work.
>
> 3)
> You can specify CVS executable there.
> Maybe ~/cvs or $HOME/cvs ??????
> Which we'd setup appropriately.
>
>
> 4)
> Hudson initialization script.
> http://wiki.hudson-ci.org/display/HUDSON/Post-initialization+script
> $HUDSON_HOME/init.groovy
> I'm not sure this runs on slave or master.
> I'd want to remove :/opt/csw/bin:, /opt/csw/bin:
> from start, :/opt/csw/bin from end, and then insert /opt/csw/bin
> somewhere, like start. That's too much Groovy for me to write,
> and get working within Hudson..there is System.getenv, but
> I don't see how to set the variables.
>
>
> 5)
> You can set "tool locations".
> I can't find elaboration on what that means.
> Maybe
> tool=cvs
> location=/opt/csw/bin/cvs
> ?
>
> 6)
> There is some mention of "PATH+".
> I tried that. Didn't work.
>
> 7)
> http://hudson.361315.n4.nabble.com/Slave-environment-and-Java-path-issues-td383751.html#a383752
>
> Thanks.? You correct that I didn't understand the difference when   
> using a non-interactive shell.
> In the end I solved the problem by putting together a simple   
> launch-slave script which sets the environment I need:
>
> #!/bin/bash
>
> export JAVA_HOME=/usr/lib/java
> ...
>
>
> 8)
> http://hudson.361315.n4.nabble.com/slave-s-PATH-change-not-picked-up-td1558100.html#a1559051
>
> You were right.? The ssh itself did not load the correct PATH (I
> couldn't see it via putty).? It turns out ssh does not read
> /etc/profile, but it does read user's .bashrc.? Go figure...
>
>
> Maybe I'll fiddle with the Hudson keys or my old key and poke around more...
>
>
> ?- Jay



-- 
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  Thu May 13 16:05:21 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 13 May 2010 16:05:21 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof ,, t, .com>,
	<F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
Message-ID: <20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>

I finally managed to get CVS working.

I postponed current9s and set up some jobs on current10s, as that
should be equivalent to your machine, Jay.

However, compilation of the cm3cg1 backed fails:

http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console

Can you have a look?

TIA,

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 May 14 00:12:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 13 May 2010 22:12:31 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, !, cg88@mail .,elegos of ,, t,
	.com>, , <F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
Message-ID: <COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>


This will be easy. Several options.
 
 - Look at 4.5.0 and how they fixed it to compile with Sun cc.
   Since they probably did, compiling gcc with Sun cc is something people are interested/willing to do.
 
 - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
 
 - Maybe just change your $PATH, but I'd prefer previous.
 
Later.
 
 - Jay


----------------------------------------
> Date: Thu, 13 May 2010 16:05:21 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
> Subject: RE: [M3devel] OpenCSW build farm access
>
> I finally managed to get CVS working.
>
> I postponed current9s and set up some jobs on current10s, as that
> should be equivalent to your machine, Jay.
>
> However, compilation of the cm3cg1 backed fails:
>
> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>
> Can you have a look?
>
> TIA,
>
> 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  Fri May 14 00:49:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 14 May 2010 00:49:24 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, !, cg88@mail .,elegos of ,, t,
	.com>, , <F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
Message-ID: <20100514004924.je7gtb922o40wck8@mail.elegosoft.com>

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

> This will be easy. Several options.
>
>  - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>    Since they probably did, compiling gcc with Sun cc is something   
> people are interested/willing to do.
>
>  - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>
>  - Maybe just change your $PATH, but I'd prefer previous.
>
> Later.

In the meantime, I put gcc in the path, which is a bit like cheating...
Now the first job has succeeded :-)
cm3-build still has other problems. I hope to have one set of working
jobs on current10s by tomorrow evening.

Olaf

>  - Jay
>
>
> ----------------------------------------
>> Date: Thu, 13 May 2010 16:05:21 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>> Subject: RE: [M3devel] OpenCSW build farm access
>>
>> I finally managed to get CVS working.
>>
>> I postponed current9s and set up some jobs on current10s, as that
>> should be equivalent to your machine, Jay.
>>
>> However, compilation of the cm3cg1 backed fails:
>>
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>
>> Can you have a look?
>>
>> TIA,
>>
>> 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
>>



-- 
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  Fri May 14 07:52:45 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 14 May 2010 07:52:45 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, !, cg88@mail .,elegos of ,, t,
	.com>, , <F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
Message-ID: <20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>

Hi again,

with some tweaking, some `standard' Hudson jobs have now complete
for cm3 on current10s.

I've now got an overview: seven packages do not compile:

http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/

m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
IMO they should compile with cc, too, though.

I'm off again now and may have a look again later,

Olaf

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

> This will be easy. Several options.
>
>  - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>    Since they probably did, compiling gcc with Sun cc is something   
> people are interested/willing to do.
>
>  - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>
>  - Maybe just change your $PATH, but I'd prefer previous.
>
> Later.
>
>  - Jay
>
>
> ----------------------------------------
>> Date: Thu, 13 May 2010 16:05:21 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>> Subject: RE: [M3devel] OpenCSW build farm access
>>
>> I finally managed to get CVS working.
>>
>> I postponed current9s and set up some jobs on current10s, as that
>> should be equivalent to your machine, Jay.
>>
>> However, compilation of the cm3cg1 backed fails:
>>
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>
>> Can you have a look?
>>
>> TIA,
>>
>> 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 May 14 08:27:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 06:27:49 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, , !, cg88@mai l,.,eleg os of ,,
	t, , .com>, , <F6, 43890B-0,
	0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>,
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>,
	<20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>
Message-ID: <COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>


Having to use gcc to compile gcc and gdb is not new, and is probably the way it has always been (from our point of view).
There is even configuration around, how to run gcc and what flags to give it, separate from SYSTEM_CC.

However, I do believe current gcc can be built with Sun cc. But I vaguely recall the patches aren't small.
I'll see.

It looks like opengl failed..and if this wasn't release branch, I'd say I broke it..
I'll look more either way.

I don't know what's up with this "libstable" stuff but I'll look more.
Could maybe be just lack of postgres or something?

More later (or maybe just commits).

?- Jay

----------------------------------------
> Date: Fri, 14 May 2010 07:52:45 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
> Subject: RE: [M3devel] OpenCSW build farm access
>
> Hi again,
>
> with some tweaking, some `standard' Hudson jobs have now complete
> for cm3 on current10s.
>
> I've now got an overview: seven packages do not compile:
>
> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/
>
> m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
> IMO they should compile with cc, too, though.
>
> I'm off again now and may have a look again later,
>
> Olaf
>
> Quoting Jay K :
>
>> This will be easy. Several options.
>>
>> - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>> Since they probably did, compiling gcc with Sun cc is something
>> people are interested/willing to do.
>>
>> - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>>
>> - Maybe just change your $PATH, but I'd prefer previous.
>>
>> Later.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> Date: Thu, 13 May 2010 16:05:21 +0200
>>> From: wagner at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>
>>> I finally managed to get CVS working.
>>>
>>> I postponed current9s and set up some jobs on current10s, as that
>>> should be equivalent to your machine, Jay.
>>>
>>> However, compilation of the cm3cg1 backed fails:
>>>
>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>>
>>> Can you have a look?
>>>
>>> TIA,
>>>
>>> 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 May 14 08:37:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 06:37:07 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
Message-ID: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>


I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).

SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
? The data in the assembly looks like. Maybe a runtime memory corruption.


PPC32_OPENBSD complains something like in TextCat that a type is missing.
?I think it used to mostly work since I deleted some install I had there.


SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
(gdb) disassem
Dump of assembler code for function RTLinker__InitRuntime:
0x00000000004bd01c <RTLinker__InitRuntime+0>:?? save? %sp, -224, %sp
0x00000000004bd020 <RTLinker__InitRuntime+4>:?? sethi? %hi(0xd18800), %l7
0x00000000004bd024 <RTLinker__InitRuntime+8>:?? add? %l7, 0x1fc, %l7??? ! 0xd189fc
0x00000000004bd028 <RTLinker__InitRuntime+12>:? call? 0x4bd010 <_m3_fault+60> 
0x00000000004bd02c <RTLinker__InitRuntime+16>:? nop 
0x00000000004bd030 <RTLinker__InitRuntime+20>:? stx? %i0, [ %fp + 0x87f ]
0x00000000004bd034 <RTLinker__InitRuntime+24>:? stx? %i1, [ %fp + 0x887 ]
0x00000000004bd038 <RTLinker__InitRuntime+28>:? stx? %i2, [ %fp + 0x88f ]
0x00000000004bd03c <RTLinker__InitRuntime+32>:? stx? %i3, [ %fp + 0x897 ]
0x00000000004bd040 <RTLinker__InitRuntime+36>:? sethi? %hi(0x942c00), %g1
0x00000000004bd044 <RTLinker__InitRuntime+40>:? or? %g1, 0x290, %g1???? ! 0x942e90 <MM_RTLinker>
0x00000000004bd048 <RTLinker__InitRuntime+44>:? ldx? [ %l7 + %g1 ], %g1? << here


This seems like it'll be tough going. :(


I think I'll try with PIC? turned off.

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Fri May 14 09:25:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 07:25:30 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	,,<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>,
	,,<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	,,<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>,
	,,<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>,
	,,<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>,
	,,<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>,
	,,<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>,
	,,<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>,
	,,<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>,
	,,<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>,
	,,<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>,
	,,<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>,
	,,<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>,
	,,<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>,
	,,<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>,
	,,<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>,
	,,<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>,
	, , <20100511090214.5bsr2f24o4os, , !, cg88@mai l, ., eleg os of , , , t,
	, .com>, 
	, <F6, 43890B-0,,0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>,
	,,<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>,
	,,<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>,
	,,<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>,
	, , <20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>, ,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>, ,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>, ,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>, ,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>, ,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>, ,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>, ,
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>, ,
	<20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>,
	<COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>
Message-ID: <COL101-W48E4F207218CBFA9DF43E3E6FD0@phx.gbl>


Olaf, it looks like the "build" part only builds "core".
Unless there is an error, then it builds more.
Isn't that wrong?

Anyway, I can see the "test" part tries to build everything anyway, and it fails creating the symlink libopengl.so.5.
Wierd.

I'll see if I can reproduce this.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com
> Date: Fri, 14 May 2010 06:27:49 +0000
> CC: m3devel at elegosoft.com; trygvis at opencsw.org; dam at baltic-online.de
> Subject: Re: [M3devel] OpenCSW build farm access
>
>
> Having to use gcc to compile gcc and gdb is not new, and is probably the way it has always been (from our point of view).
> There is even configuration around, how to run gcc and what flags to give it, separate from SYSTEM_CC.
>
> However, I do believe current gcc can be built with Sun cc. But I vaguely recall the patches aren't small.
> I'll see.
>
> It looks like opengl failed..and if this wasn't release branch, I'd say I broke it..
> I'll look more either way.
>
> I don't know what's up with this "libstable" stuff but I'll look more.
> Could maybe be just lack of postgres or something?
>
> More later (or maybe just commits).
>
>  - Jay
>
> ----------------------------------------
>> Date: Fri, 14 May 2010 07:52:45 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>> Subject: RE: [M3devel] OpenCSW build farm access
>>
>> Hi again,
>>
>> with some tweaking, some `standard' Hudson jobs have now complete
>> for cm3 on current10s.
>>
>> I've now got an overview: seven packages do not compile:
>>
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/
>>
>> m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
>> IMO they should compile with cc, too, though.
>>
>> I'm off again now and may have a look again later,
>>
>> Olaf
>>
>> Quoting Jay K :
>>
>>> This will be easy. Several options.
>>>
>>> - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>>> Since they probably did, compiling gcc with Sun cc is something
>>> people are interested/willing to do.
>>>
>>> - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>>>
>>> - Maybe just change your $PATH, but I'd prefer previous.
>>>
>>> Later.
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> Date: Thu, 13 May 2010 16:05:21 +0200
>>>> From: wagner at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>>
>>>> I finally managed to get CVS working.
>>>>
>>>> I postponed current9s and set up some jobs on current10s, as that
>>>> should be equivalent to your machine, Jay.
>>>>
>>>> However, compilation of the cm3cg1 backed fails:
>>>>
>>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>>>
>>>> Can you have a look?
>>>>
>>>> TIA,
>>>>
>>>> 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 May 14 11:08:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 09:08:58 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>
Message-ID: <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>


Hm. Something is wrong on many platforms, in head, at least with my boot archives.
? PPC_DARWIN, SOLsun, I386_LINUX
I'll figure it out. Hopefully soon.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Fri, 14 May 2010 06:37:07 +0000
> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>
> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>   The data in the assembly looks like. Maybe a runtime memory corruption.
>
>
> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>  I think it used to mostly work since I deleted some install I had there.
>
>
> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
> (gdb) disassem
> Dump of assembler code for function RTLinker__InitRuntime:
> 0x00000000004bd01c :   save  %sp, -224, %sp
> 0x00000000004bd020 :   sethi  %hi(0xd18800), %l7
> 0x00000000004bd024 :   add  %l7, 0x1fc, %l7    ! 0xd189fc
> 0x00000000004bd028 :  call  0x4bd010 <_m3_fault+60>
> 0x00000000004bd02c :  nop
> 0x00000000004bd030 :  stx  %i0, [ %fp + 0x87f ]
> 0x00000000004bd034 :  stx  %i1, [ %fp + 0x887 ]
> 0x00000000004bd038 :  stx  %i2, [ %fp + 0x88f ]
> 0x00000000004bd03c :  stx  %i3, [ %fp + 0x897 ]
> 0x00000000004bd040 :  sethi  %hi(0x942c00), %g1
> 0x00000000004bd044 :  or  %g1, 0x290, %g1     ! 0x942e90 
> 0x00000000004bd048 :  ldx  [ %l7 + %g1 ], %g1  << here
>
>
> This seems like it'll be tough going. :(
>
>
> I think I'll try with PIC  turned off.
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Fri May 14 12:27:36 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 10:27:36 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>
Message-ID: <COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>


ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
Then I'll have to narrow it down some -- there are two main sets of changes:
?- my changes to set operations ? 
?- my change to div/mod
?- Tony's to bit field operations? 

It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.

I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
to keep them if they don't work.
?(Well, hopefully the NT386 versions can stay. :) )

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Fri, 14 May 2010 09:08:58 +0000
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>   PPC_DARWIN, SOLsun, I386_LINUX
> I'll figure it out. Hopefully soon.
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Fri, 14 May 2010 06:37:07 +0000
>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>
>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>
>>
>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>> I think it used to mostly work since I deleted some install I had there.
>>
>>
>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>> (gdb) disassem
>> Dump of assembler code for function RTLinker__InitRuntime:
>> 0x00000000004bd01c : save %sp, -224, %sp
>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>> 0x00000000004bd02c : nop
>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>
>>
>> This seems like it'll be tough going. :(
>>
>>
>> I think I'll try with PIC turned off.
>>
>> - Jay
>>
>>
>
 		 	   		  

From hosking at cs.purdue.edu  Fri May 14 15:59:02 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 14 May 2010 09:59:02 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>
Message-ID: <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>

Argh.  I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.

Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels.  I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution.  This is fragile stuff... and it may just be a bug in gcc that we are exercising.

It may be that we just need to update the backend to a newer version of gcc.  It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been.  Problem is that newer gcc may not play nice with older targets.  I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.

On 14 May 2010, at 06:27, Jay K wrote:

> 
> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
> Then I'll have to narrow it down some -- there are two main sets of changes:
>  - my changes to set operations   
>  - my change to div/mod
>  - Tony's to bit field operations  
> 
> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
> 
> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
> to keep them if they don't work.
>  (Well, hopefully the NT386 versions can stay. :) )
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Fri, 14 May 2010 09:08:58 +0000
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>  PPC_DARWIN, SOLsun, I386_LINUX
>> I'll figure it out. Hopefully soon.
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> 
>>> 
>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>> 
>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>> 
>>> 
>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>> I think it used to mostly work since I deleted some install I had there.
>>> 
>>> 
>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>> (gdb) disassem
>>> Dump of assembler code for function RTLinker__InitRuntime:
>>> 0x00000000004bd01c : save %sp, -224, %sp
>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>> 0x00000000004bd02c : nop
>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>> 
>>> 
>>> This seems like it'll be tough going. :(
>>> 
>>> 
>>> I think I'll try with PIC turned off.
>>> 
>>> - Jay
>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Fri May 14 19:58:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 17:58:29 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>
Message-ID: <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>


I don't think anything I've been fiddling with has been dropped by gcc, yet.
?I might have depended on Irix o32 to get up to a working gcc, but no matter.
?I agree if they drop it, we have to.
?Though we could also keep multiple gcc versions if there was really something we wanted,
? but that's not likely.
?A C generating backend also solves this.


I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
But I won't guarantee that now and am very willing to undo them if there is a problem.
?(big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).


?I don't remember about div/mod.
?While it seems "obvious" that the change is correct, it could be that that part of
?gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?


I'm also not optimizing at all.


I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
easily, and I'm also not keen on the huge testing matrix.
(I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)


If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.


Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
?SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).


?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 09:59:02 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>
> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>
> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>
> On 14 May 2010, at 06:27, Jay K wrote:
>
>>
>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>> Then I'll have to narrow it down some -- there are two main sets of changes:
>> - my changes to set operations
>> - my change to div/mod
>> - Tony's to bit field operations
>>
>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>
>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>> to keep them if they don't work.
>> (Well, hopefully the NT386 versions can stay. :) )
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>> PPC_DARWIN, SOLsun, I386_LINUX
>>> I'll figure it out. Hopefully soon.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>
>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>
>>>>
>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>> I think it used to mostly work since I deleted some install I had there.
>>>>
>>>>
>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>> (gdb) disassem
>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>> 0x00000000004bd02c : nop
>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>
>>>>
>>>> This seems like it'll be tough going. :(
>>>>
>>>>
>>>> I think I'll try with PIC turned off.
>>>>
>>>> - Jay
>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Fri May 14 20:25:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 18:25:59 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>,
	, , <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
Message-ID: <COL101-W19A08D5003AAF4F70340CCE6FD0@phx.gbl>


I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.


I have some extra time today, so, plan:
? retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
? test undo just the bitfield insert/extract change, see if that is the problem 
? work through the others if not 
? Possibly verify mod/div test coverage (unless it is the problem, in which
? case if I put it back, no need for test coverage, probably nobody will ever
? touch it again, which is fine. :) )
?I'm pretty sure I tested the set stuff well because I was very nervous but
? if others are ruled out I'll undo or test it.
? (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
?set changes. Only through experimentation/testing could I know that
?the definition of bit indices matched up between hand.c and the btc/bts instructions,
?it appeared to be a very convenient coincidence.)


I am surprised that I386_* working and broken.
I would think wordsize and endian is all that matters here.


I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
But moving up to 4.4.x or 4.5.x is welcome too. :)


?- Jay
?

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 17:58:29 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>  I might have depended on Irix o32 to get up to a working gcc, but no matter.
>  I agree if they drop it, we have to.
>  Though we could also keep multiple gcc versions if there was really something we wanted,
>   but that's not likely.
>  A C generating backend also solves this.
>
>
> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
> But I won't guarantee that now and am very willing to undo them if there is a problem.
>  (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>
>
>  I don't remember about div/mod.
>  While it seems "obvious" that the change is correct, it could be that that part of
>  gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>
>
> I'm also not optimizing at all.
>
>
> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
> easily, and I'm also not keen on the huge testing matrix.
> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>
>
> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>
>
> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>  SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>
>
>  - Jay
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 09:59:02 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>
>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>
>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>
>> On 14 May 2010, at 06:27, Jay K wrote:
>>
>>>
>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>> - my changes to set operations
>>> - my change to div/mod
>>> - Tony's to bit field operations
>>>
>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>
>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>> to keep them if they don't work.
>>> (Well, hopefully the NT386 versions can stay. :) )
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>> I'll figure it out. Hopefully soon.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: m3devel at elegosoft.com
>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>
>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>
>>>>>
>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>
>>>>>
>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>> (gdb) disassem
>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>> 0x00000000004bd02c : nop
>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>
>>>>>
>>>>> This seems like it'll be tough going. :(
>>>>>
>>>>>
>>>>> I think I'll try with PIC turned off.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From wagner at elegosoft.com  Sat May 15 00:09:13 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 15 May 2010 00:09:13 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W48E4F207218CBFA9DF43E3E6FD0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	,,<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>,
	,,<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	,,<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>,
	,,<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>,
	,,<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>,
	,,<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>,
	,,<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>,
	,,<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>,
	,,<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>,
	,,<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>,
	,,<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>,
	,,<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>,
	,,<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>,
	,,<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>,
	,,<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>,
	,,<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>,
	,,<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>,
	, , <20100511090214.5bsr2f24o4os, , !, cg88@mai l, ., eleg os of , , , t,
	, .com>, 
	, <F6, 43890B-0,,0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>,
	,,<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>,
	,,<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>,
	,,<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>,
	, , <20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>, ,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>, ,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>, ,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>, ,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>, ,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>, ,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>, ,
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>, ,
	<20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>,
	<COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>
	<COL101-W48E4F207218CBFA9DF43E3E6FD0@phx.gbl>
Message-ID: <20100515000913.3zzs4eu40swsgg0k@mail.elegosoft.com>

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

> Olaf, it looks like the "build" part only builds "core".
> Unless there is an error, then it builds more.
> Isn't that wrong?

I think it's always build just core. Why should it build more in case
of an error?

All packages are built and tested in the test-all-pkgs jobs.

> Anyway, I can see the "test" part tries to build everything anyway,   
> and it fails creating the symlink libopengl.so.5.
> Wierd.
>
> I'll see if I can reproduce this.

Strange. But to answer a question from your previous mail,
this is still the release branch. I just tried to port the existing
jobs now running on your machine first.

We can easily switch them to the trunk head though.

Olaf

> ?- Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: wagner at elegosoft.com
>> Date: Fri, 14 May 2010 06:27:49 +0000
>> CC: m3devel at elegosoft.com; trygvis at opencsw.org; dam at baltic-online.de
>> Subject: Re: [M3devel] OpenCSW build farm access
>>
>>
>> Having to use gcc to compile gcc and gdb is not new, and is   
>> probably the way it has always been (from our point of view).
>> There is even configuration around, how to run gcc and what flags   
>> to give it, separate from SYSTEM_CC.
>>
>> However, I do believe current gcc can be built with Sun cc. But I   
>> vaguely recall the patches aren't small.
>> I'll see.
>>
>> It looks like opengl failed..and if this wasn't release branch, I'd  
>>  say I broke it..
>> I'll look more either way.
>>
>> I don't know what's up with this "libstable" stuff but I'll look more.
>> Could maybe be just lack of postgres or something?
>>
>> More later (or maybe just commits).
>>
>>  - Jay
>>
>> ----------------------------------------
>>> Date: Fri, 14 May 2010 07:52:45 +0200
>>> From: wagner at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>
>>> Hi again,
>>>
>>> with some tweaking, some `standard' Hudson jobs have now complete
>>> for cm3 on current10s.
>>>
>>> I've now got an overview: seven packages do not compile:
>>>
>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/
>>>
>>> m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
>>> IMO they should compile with cc, too, though.
>>>
>>> I'm off again now and may have a look again later,
>>>
>>> Olaf
>>>
>>> Quoting Jay K :
>>>
>>>> This will be easy. Several options.
>>>>
>>>> - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>>>> Since they probably did, compiling gcc with Sun cc is something
>>>> people are interested/willing to do.
>>>>
>>>> - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>>>>
>>>> - Maybe just change your $PATH, but I'd prefer previous.
>>>>
>>>> Later.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Thu, 13 May 2010 16:05:21 +0200
>>>>> From: wagner at elegosoft.com
>>>>> To: jay.krell at cornell.edu
>>>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>>>
>>>>> I finally managed to get CVS working.
>>>>>
>>>>> I postponed current9s and set up some jobs on current10s, as that
>>>>> should be equivalent to your machine, Jay.
>>>>>
>>>>> However, compilation of the cm3cg1 backed fails:
>>>>>
>>>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>>>>
>>>>> Can you have a look?
>>>>>
>>>>> TIA,
>>>>>
>>>>> 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
>>>
>>
>



-- 
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  Sat May 15 00:13:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 22:13:58 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
Message-ID: <COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>


So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....

? - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
> Date: Fri, 14 May 2010 18:25:59 +0000
>
>
> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>
>
> I have some extra time today, so, plan:
>   retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>   test undo just the bitfield insert/extract change, see if that is the problem
>   work through the others if not
>   Possibly verify mod/div test coverage (unless it is the problem, in which
>   case if I put it back, no need for test coverage, probably nobody will ever
>   touch it again, which is fine. :) )
>  I'm pretty sure I tested the set stuff well because I was very nervous but
>   if others are ruled out I'll undo or test it.
>   (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>  set changes. Only through experimentation/testing could I know that
>  the definition of bit indices matched up between hand.c and the btc/bts instructions,
>  it appeared to be a very convenient coincidence.)
>
>
> I am surprised that I386_* working and broken.
> I would think wordsize and endian is all that matters here.
>
>
> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
> But moving up to 4.4.x or 4.5.x is welcome too. :)
>
>
>  - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 17:58:29 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>> I agree if they drop it, we have to.
>> Though we could also keep multiple gcc versions if there was really something we wanted,
>> but that's not likely.
>> A C generating backend also solves this.
>>
>>
>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>
>>
>> I don't remember about div/mod.
>> While it seems "obvious" that the change is correct, it could be that that part of
>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>
>>
>> I'm also not optimizing at all.
>>
>>
>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>> easily, and I'm also not keen on the huge testing matrix.
>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>
>>
>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>
>>
>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>
>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>
>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>
>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>
>>>>
>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>> - my changes to set operations
>>>> - my change to div/mod
>>>> - Tony's to bit field operations
>>>>
>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>
>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>> to keep them if they don't work.
>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: m3devel at elegosoft.com
>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>> I'll figure it out. Hopefully soon.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: m3devel at elegosoft.com
>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>
>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>
>>>>>>
>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>
>>>>>>
>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>> (gdb) disassem
>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>> 0x00000000004bd02c : nop
>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>
>>>>>>
>>>>>> This seems like it'll be tough going. :(
>>>>>>
>>>>>>
>>>>>> I think I'll try with PIC turned off.
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 02:24:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 00:24:03 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>,
	, , <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>
Message-ID: <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>


Tony I think it is your change to extract_mn.
Try it with SOLsun for example.
I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):


diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
77,78c77,78
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 22, %g1
> ??? srl??? %g1, 31, %g1
118,119c118,119
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 22, %g1
> ??? srl??? %g1, 31, %g1
197,198c197,198
< ??? srl??? %g1, 21, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 21, %g1
> ??? srl??? %g1, 31, %g1
236,237c236,237
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 22, %g1
> ??? srl??? %g1, 31, %g1
273,274c273,274
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1


This is not optimized.
They seem equally optimal, but very different.
? Assuming shifts are fast. Could be srl+and is faster than sll+srl.
? srl+and is clearer.
?I don't remember which of these worked.


< ??? srl??? %g1, 22, %g1

< ??? and??? %g1, 1, %g1

---

> ??? sll??? %g1, 22, %g1

> ??? srl??? %g1, 31, %g1



I read the first as:
? extract bit 22, plus or minus 1
vs.
? extract bit 32-22=10, plus or minus 1.


It would probably be ok to move bits around, but insert would have to match.


?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 22:13:58 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>
>   - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> Date: Fri, 14 May 2010 18:25:59 +0000
>>
>>
>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>
>>
>> I have some extra time today, so, plan:
>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>> test undo just the bitfield insert/extract change, see if that is the problem
>> work through the others if not
>> Possibly verify mod/div test coverage (unless it is the problem, in which
>> case if I put it back, no need for test coverage, probably nobody will ever
>> touch it again, which is fine. :) )
>> I'm pretty sure I tested the set stuff well because I was very nervous but
>> if others are ruled out I'll undo or test it.
>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>> set changes. Only through experimentation/testing could I know that
>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>> it appeared to be a very convenient coincidence.)
>>
>>
>> I am surprised that I386_* working and broken.
>> I would think wordsize and endian is all that matters here.
>>
>>
>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>> I agree if they drop it, we have to.
>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>> but that's not likely.
>>> A C generating backend also solves this.
>>>
>>>
>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>
>>>
>>> I don't remember about div/mod.
>>> While it seems "obvious" that the change is correct, it could be that that part of
>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>
>>>
>>> I'm also not optimizing at all.
>>>
>>>
>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>> easily, and I'm also not keen on the huge testing matrix.
>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>
>>>
>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>
>>>
>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>
>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>
>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>
>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>
>>>>>
>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>> - my changes to set operations
>>>>> - my change to div/mod
>>>>> - Tony's to bit field operations
>>>>>
>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>
>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>> to keep them if they don't work.
>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: m3devel at elegosoft.com
>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>> I'll figure it out. Hopefully soon.
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>
>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>
>>>>>>>
>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>
>>>>>>>
>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>> (gdb) disassem
>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>> 0x00000000004bd02c : nop
>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>
>>>>>>>
>>>>>>> This seems like it'll be tough going. :(
>>>>>>>
>>>>>>>
>>>>>>> I think I'll try with PIC turned off.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 03:07:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 01:07:27 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,
	, , , , <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , 
	, <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,
	, , <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
Message-ID: <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>


> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1

Er.
first: a = (a>> 22) & 1;
second: a = (a << 22)>> 31;

are actually darn close, maybe the same.
Let's just be lame and test in C:

#include <stdio.h>
int main()
{
unsigned a = ~0;
unsigned b = (a>> 22) & 1;
unsigned c = (a << 22)>> 31;
printf("%x %x\n", b, c);
return 0;
}

both print 1. So I remain a bit uncertain.
I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
I might dig more before commiting the undo.
Maybe bit fields of multiple bits are the only ones broken.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:24:03 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> Tony I think it is your change to extract_mn.
> Try it with SOLsun for example.
> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>
>
> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
> 77,78c77,78
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 118,119c118,119
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 197,198c197,198
> <     srl    %g1, 21, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 21, %g1
>>     srl    %g1, 31, %g1
> 236,237c236,237
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 273,274c273,274
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
>
>
> This is not optimized.
> They seem equally optimal, but very different.
>   Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>   srl+and is clearer.
>  I don't remember which of these worked.
>
>
> <     srl    %g1, 22, %g1
>
> <     and    %g1, 1, %g1
>
> ---
>
>>     sll    %g1, 22, %g1
>
>>     srl    %g1, 31, %g1
>
>
>
> I read the first as:
>   extract bit 22, plus or minus 1
> vs.
>   extract bit 32-22=10, plus or minus 1.
>
>
> It would probably be ok to move bits around, but insert would have to match.
>
>
>  - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 22:13:58 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>
>>>
>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>
>>>
>>> I have some extra time today, so, plan:
>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>> test undo just the bitfield insert/extract change, see if that is the problem
>>> work through the others if not
>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>> case if I put it back, no need for test coverage, probably nobody will ever
>>> touch it again, which is fine. :) )
>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>> if others are ruled out I'll undo or test it.
>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>> set changes. Only through experimentation/testing could I know that
>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>> it appeared to be a very convenient coincidence.)
>>>
>>>
>>> I am surprised that I386_* working and broken.
>>> I would think wordsize and endian is all that matters here.
>>>
>>>
>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>> I agree if they drop it, we have to.
>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>> but that's not likely.
>>>> A C generating backend also solves this.
>>>>
>>>>
>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>
>>>>
>>>> I don't remember about div/mod.
>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>
>>>>
>>>> I'm also not optimizing at all.
>>>>
>>>>
>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>> easily, and I'm also not keen on the huge testing matrix.
>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>
>>>>
>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>
>>>>
>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>
>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>
>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>
>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>
>>>>>>
>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>> - my changes to set operations
>>>>>> - my change to div/mod
>>>>>> - Tony's to bit field operations
>>>>>>
>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>
>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>> to keep them if they don't work.
>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>
>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>
>>>>>>>>
>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>
>>>>>>>>
>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>> (gdb) disassem
>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>
>>>>>>>>
>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>
>>>>>>>>
>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 03:29:01 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 01:29:01 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,,, , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , ,,,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,,, ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,
	, , <COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
Message-ID: <COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>


Well I'm feeling dumb. That test case surely would print 1 for almost anything.
A more accurate one, which shows a problem, is:

#include <stdio.h>

unsigned F1(unsigned a) { return ((a>> 22) & 1); }
unsigned F2(unsigned a) { return ((a << 22)>> 31); }

int main()
{
??? unsigned a = 1 << 22;
??? printf("%x %x\n", F1(a), F2(a));
??? return 0;
}

But I'm still having trouble convincing myself.
I guess the second might give you the 10th bit.
Er, the 9th.

#include <stdio.h>

unsigned F1(unsigned a) { return ((a>> 22) & 1); }
unsigned F2(unsigned a) { return ((a << 22)>> 31); }

int main()
{
??? unsigned a = 1 << 22;
??? printf("%x %x\n", F1(a), F2(a));

??? a = 1 << 9;
??? printf("%x %x\n", F1(a), F2(a));
??? return 0;
}

1 0
0 1

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 01:07:27 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>
> Er.
> first: a = (a>> 22) & 1;
> second: a = (a << 22)>> 31;
>
> are actually darn close, maybe the same.
> Let's just be lame and test in C:
>
> #include 
> int main()
> {
> unsigned a = ~0;
> unsigned b = (a>> 22) & 1;
> unsigned c = (a << 22)>> 31;
> printf("%x %x\n", b, c);
> return 0;
> }
>
> both print 1. So I remain a bit uncertain.
> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
> I might dig more before commiting the undo.
> Maybe bit fields of multiple bits are the only ones broken.
>
>  - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 00:24:03 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> Tony I think it is your change to extract_mn.
>> Try it with SOLsun for example.
>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>
>>
>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>> 77,78c77,78
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>> 118,119c118,119
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>> 197,198c197,198
>> < srl %g1, 21, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 21, %g1
>>> srl %g1, 31, %g1
>> 236,237c236,237
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>> 273,274c273,274
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>>
>>
>> This is not optimized.
>> They seem equally optimal, but very different.
>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>> srl+and is clearer.
>> I don't remember which of these worked.
>>
>>
>> < srl %g1, 22, %g1
>>
>> < and %g1, 1, %g1
>>
>> ---
>>
>>> sll %g1, 22, %g1
>>
>>> srl %g1, 31, %g1
>>
>>
>>
>> I read the first as:
>> extract bit 22, plus or minus 1
>> vs.
>> extract bit 32-22=10, plus or minus 1.
>>
>>
>> It would probably be ok to move bits around, but insert would have to match.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>
>>>>
>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>
>>>>
>>>> I have some extra time today, so, plan:
>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>> work through the others if not
>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>> touch it again, which is fine. :) )
>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>> if others are ruled out I'll undo or test it.
>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>> set changes. Only through experimentation/testing could I know that
>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>> it appeared to be a very convenient coincidence.)
>>>>
>>>>
>>>> I am surprised that I386_* working and broken.
>>>> I would think wordsize and endian is all that matters here.
>>>>
>>>>
>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>> I agree if they drop it, we have to.
>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>> but that's not likely.
>>>>> A C generating backend also solves this.
>>>>>
>>>>>
>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>
>>>>>
>>>>> I don't remember about div/mod.
>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>
>>>>>
>>>>> I'm also not optimizing at all.
>>>>>
>>>>>
>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>
>>>>>
>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>
>>>>>
>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>
>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>
>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>
>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>
>>>>>>>
>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>> - my changes to set operations
>>>>>>> - my change to div/mod
>>>>>>> - Tony's to bit field operations
>>>>>>>
>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>
>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>> to keep them if they don't work.
>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>
>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>> (gdb) disassem
>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 05:10:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 03:10:54 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,,, , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, ,
	,,,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, ,
	,,,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,,,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,,, ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>,
	, , <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>
Message-ID: <COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>


http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html

BIT_FIELD_REF considered harmful

We should try to use COMPONENT_REF instead.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 01:29:01 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
> A more accurate one, which shows a problem, is:
>
> #include 
>
> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>
> int main()
> {
>     unsigned a = 1 << 22;
>     printf("%x %x\n", F1(a), F2(a));
>     return 0;
> }
>
> But I'm still having trouble convincing myself.
> I guess the second might give you the 10th bit.
> Er, the 9th.
>
> #include 
>
> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>
> int main()
> {
>     unsigned a = 1 << 22;
>     printf("%x %x\n", F1(a), F2(a));
>
>     a = 1 << 9;
>     printf("%x %x\n", F1(a), F2(a));
>     return 0;
> }
>
> 1 0
> 0 1
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 01:07:27 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>
>> Er.
>> first: a = (a>> 22) & 1;
>> second: a = (a << 22)>> 31;
>>
>> are actually darn close, maybe the same.
>> Let's just be lame and test in C:
>>
>> #include
>> int main()
>> {
>> unsigned a = ~0;
>> unsigned b = (a>> 22) & 1;
>> unsigned c = (a << 22)>> 31;
>> printf("%x %x\n", b, c);
>> return 0;
>> }
>>
>> both print 1. So I remain a bit uncertain.
>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>> I might dig more before commiting the undo.
>> Maybe bit fields of multiple bits are the only ones broken.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Tony I think it is your change to extract_mn.
>>> Try it with SOLsun for example.
>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>
>>>
>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>> 77,78c77,78
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>> 118,119c118,119
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>> 197,198c197,198
>>> < srl %g1, 21, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 21, %g1
>>>> srl %g1, 31, %g1
>>> 236,237c236,237
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>> 273,274c273,274
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>>
>>>
>>> This is not optimized.
>>> They seem equally optimal, but very different.
>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>> srl+and is clearer.
>>> I don't remember which of these worked.
>>>
>>>
>>> < srl %g1, 22, %g1
>>>
>>> < and %g1, 1, %g1
>>>
>>> ---
>>>
>>>> sll %g1, 22, %g1
>>>
>>>> srl %g1, 31, %g1
>>>
>>>
>>>
>>> I read the first as:
>>> extract bit 22, plus or minus 1
>>> vs.
>>> extract bit 32-22=10, plus or minus 1.
>>>
>>>
>>> It would probably be ok to move bits around, but insert would have to match.
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>
>>>>>
>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>
>>>>>
>>>>> I have some extra time today, so, plan:
>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>> work through the others if not
>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>> touch it again, which is fine. :) )
>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>> if others are ruled out I'll undo or test it.
>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>> set changes. Only through experimentation/testing could I know that
>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>> it appeared to be a very convenient coincidence.)
>>>>>
>>>>>
>>>>> I am surprised that I386_* working and broken.
>>>>> I would think wordsize and endian is all that matters here.
>>>>>
>>>>>
>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>> I agree if they drop it, we have to.
>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>> but that's not likely.
>>>>>> A C generating backend also solves this.
>>>>>>
>>>>>>
>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>
>>>>>>
>>>>>> I don't remember about div/mod.
>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>
>>>>>>
>>>>>> I'm also not optimizing at all.
>>>>>>
>>>>>>
>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>
>>>>>>
>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>
>>>>>>
>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: hosking at cs.purdue.edu
>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>
>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>
>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>
>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>> - my changes to set operations
>>>>>>>> - my change to div/mod
>>>>>>>> - Tony's to bit field operations
>>>>>>>>
>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>
>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>> to keep them if they don't work.
>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>
>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>> (gdb) disassem
>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From hosking at cs.purdue.edu  Sat May 15 06:13:20 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 00:13:20 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
Message-ID: <00A2CBB5-0BD0-43B0-8C2B-5D7296048DAF@cs.purdue.edu>

Yeah.   Looks broken.  Please de-optimize extract_mn to what it was before.

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 14 May 2010, at 20:24, Jay K wrote:

> 
> Tony I think it is your change to extract_mn.
> Try it with SOLsun for example.
> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
> 
> 
> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
> 77,78c77,78
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 118,119c118,119
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 197,198c197,198
> <     srl    %g1, 21, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 21, %g1
>>     srl    %g1, 31, %g1
> 236,237c236,237
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 273,274c273,274
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> 
> 
> This is not optimized.
> They seem equally optimal, but very different.
>   Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>   srl+and is clearer.
>  I don't remember which of these worked.
> 
> 
> <     srl    %g1, 22, %g1
> 
> <     and    %g1, 1, %g1
> 
> ---
> 
>>     sll    %g1, 22, %g1
> 
>>     srl    %g1, 31, %g1
> 
> 
> 
> I read the first as:
>   extract bit 22, plus or minus 1
> vs.
>   extract bit 32-22=10, plus or minus 1.
> 
> 
> It would probably be ok to move bits around, but insert would have to match.
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 22:13:58 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>> 
>>  - Jay
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>> 
>>> 
>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>> 
>>> 
>>> I have some extra time today, so, plan:
>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>> test undo just the bitfield insert/extract change, see if that is the problem
>>> work through the others if not
>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>> case if I put it back, no need for test coverage, probably nobody will ever
>>> touch it again, which is fine. :) )
>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>> if others are ruled out I'll undo or test it.
>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>> set changes. Only through experimentation/testing could I know that
>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>> it appeared to be a very convenient coincidence.)
>>> 
>>> 
>>> I am surprised that I386_* working and broken.
>>> I would think wordsize and endian is all that matters here.
>>> 
>>> 
>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> 
>>>> 
>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>> I agree if they drop it, we have to.
>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>> but that's not likely.
>>>> A C generating backend also solves this.
>>>> 
>>>> 
>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>> 
>>>> 
>>>> I don't remember about div/mod.
>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>> 
>>>> 
>>>> I'm also not optimizing at all.
>>>> 
>>>> 
>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>> easily, and I'm also not keen on the huge testing matrix.
>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>> 
>>>> 
>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>> 
>>>> 
>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> 
>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>> 
>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>> 
>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>> 
>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>> 
>>>>>> 
>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>> - my changes to set operations
>>>>>> - my change to div/mod
>>>>>> - Tony's to bit field operations
>>>>>> 
>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>> 
>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>> to keep them if they don't work.
>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> 
>>>>>>> 
>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>> 
>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>> (gdb) disassem
>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>> 
>>>>>>>> 
>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>> 
>>>>>>>> - Jay
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  

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

From hosking at cs.purdue.edu  Sat May 15 06:14:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 00:14:08 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
Message-ID: <131F4BA5-0960-429D-B711-304FEE55A4F1@cs.purdue.edu>

It would be great if we could understand what is going on here, because as I recall the code looked to be correct, at least on x86.

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 14 May 2010, at 21:07, Jay K wrote:

> 
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
> 
> Er.
> first: a = (a>> 22) & 1;
> second: a = (a << 22)>> 31;
> 
> are actually darn close, maybe the same.
> Let's just be lame and test in C:
> 
> #include <stdio.h>
> int main()
> {
> unsigned a = ~0;
> unsigned b = (a>> 22) & 1;
> unsigned c = (a << 22)>> 31;
> printf("%x %x\n", b, c);
> return 0;
> }
> 
> both print 1. So I remain a bit uncertain.
> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
> I might dig more before commiting the undo.
> Maybe bit fields of multiple bits are the only ones broken.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 00:24:03 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> Tony I think it is your change to extract_mn.
>> Try it with SOLsun for example.
>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>> 
>> 
>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>> 77,78c77,78
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
>> 118,119c118,119
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
>> 197,198c197,198
>> <     srl    %g1, 21, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 21, %g1
>>>    srl    %g1, 31, %g1
>> 236,237c236,237
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
>> 273,274c273,274
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> 
>> 
>> This is not optimized.
>> They seem equally optimal, but very different.
>>  Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>  srl+and is clearer.
>> I don't remember which of these worked.
>> 
>> 
>> <     srl    %g1, 22, %g1
>> 
>> <     and    %g1, 1, %g1
>> 
>> ---
>> 
>>>    sll    %g1, 22, %g1
>> 
>>>    srl    %g1, 31, %g1
>> 
>> 
>> 
>> I read the first as:
>>  extract bit 22, plus or minus 1
>> vs.
>>  extract bit 32-22=10, plus or minus 1.
>> 
>> 
>> It would probably be ok to move bits around, but insert would have to match.
>> 
>> 
>> - Jay
>> 
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> 
>>> 
>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>> 
>>>> 
>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>> 
>>>> 
>>>> I have some extra time today, so, plan:
>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>> work through the others if not
>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>> touch it again, which is fine. :) )
>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>> if others are ruled out I'll undo or test it.
>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>> set changes. Only through experimentation/testing could I know that
>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>> it appeared to be a very convenient coincidence.)
>>>> 
>>>> 
>>>> I am surprised that I386_* working and broken.
>>>> I would think wordsize and endian is all that matters here.
>>>> 
>>>> 
>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> 
>>>>> 
>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>> I agree if they drop it, we have to.
>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>> but that's not likely.
>>>>> A C generating backend also solves this.
>>>>> 
>>>>> 
>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>> 
>>>>> 
>>>>> I don't remember about div/mod.
>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>> 
>>>>> 
>>>>> I'm also not optimizing at all.
>>>>> 
>>>>> 
>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>> 
>>>>> 
>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>> 
>>>>> 
>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>> 
>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>> 
>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>> 
>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>> 
>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>> 
>>>>>>> 
>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>> - my changes to set operations
>>>>>>> - my change to div/mod
>>>>>>> - Tony's to bit field operations
>>>>>>> 
>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>> 
>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>> to keep them if they don't work.
>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>> 
>>>>>>>> - Jay
>>>>>>>> 
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>> 
>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>> (gdb) disassem
>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>> 
>>>>>>>>> - Jay
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  

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

From hosking at cs.purdue.edu  Sat May 15 06:14:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 00:14:54 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>
Message-ID: <558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>

COMPONENT_REF is difficult because of the lack of type info I think.  Please revert to what it used to be.


On 14 May 2010, at 23:10, Jay K wrote:

> 
> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
> 
> BIT_FIELD_REF considered harmful
> 
> We should try to use COMPONENT_REF instead.
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 01:29:01 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>> A more accurate one, which shows a problem, is:
>> 
>> #include 
>> 
>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>> 
>> int main()
>> {
>>    unsigned a = 1 << 22;
>>    printf("%x %x\n", F1(a), F2(a));
>>    return 0;
>> }
>> 
>> But I'm still having trouble convincing myself.
>> I guess the second might give you the 10th bit.
>> Er, the 9th.
>> 
>> #include 
>> 
>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>> 
>> int main()
>> {
>>    unsigned a = 1 << 22;
>>    printf("%x %x\n", F1(a), F2(a));
>> 
>>    a = 1 << 9;
>>    printf("%x %x\n", F1(a), F2(a));
>>    return 0;
>> }
>> 
>> 1 0
>> 0 1
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> 
>>> 
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>> 
>>> Er.
>>> first: a = (a>> 22) & 1;
>>> second: a = (a << 22)>> 31;
>>> 
>>> are actually darn close, maybe the same.
>>> Let's just be lame and test in C:
>>> 
>>> #include
>>> int main()
>>> {
>>> unsigned a = ~0;
>>> unsigned b = (a>> 22) & 1;
>>> unsigned c = (a << 22)>> 31;
>>> printf("%x %x\n", b, c);
>>> return 0;
>>> }
>>> 
>>> both print 1. So I remain a bit uncertain.
>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>> I might dig more before commiting the undo.
>>> Maybe bit fields of multiple bits are the only ones broken.
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> 
>>>> 
>>>> Tony I think it is your change to extract_mn.
>>>> Try it with SOLsun for example.
>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>> 
>>>> 
>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>> 77,78c77,78
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>>> 118,119c118,119
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>>> 197,198c197,198
>>>> < srl %g1, 21, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 21, %g1
>>>>> srl %g1, 31, %g1
>>>> 236,237c236,237
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>>> 273,274c273,274
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> 
>>>> 
>>>> This is not optimized.
>>>> They seem equally optimal, but very different.
>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>> srl+and is clearer.
>>>> I don't remember which of these worked.
>>>> 
>>>> 
>>>> < srl %g1, 22, %g1
>>>> 
>>>> < and %g1, 1, %g1
>>>> 
>>>> ---
>>>> 
>>>>> sll %g1, 22, %g1
>>>> 
>>>>> srl %g1, 31, %g1
>>>> 
>>>> 
>>>> 
>>>> I read the first as:
>>>> extract bit 22, plus or minus 1
>>>> vs.
>>>> extract bit 32-22=10, plus or minus 1.
>>>> 
>>>> 
>>>> It would probably be ok to move bits around, but insert would have to match.
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> 
>>>>> 
>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>> 
>>>>>> 
>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>> 
>>>>>> 
>>>>>> I have some extra time today, so, plan:
>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>> work through the others if not
>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>> touch it again, which is fine. :) )
>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>> if others are ruled out I'll undo or test it.
>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>> it appeared to be a very convenient coincidence.)
>>>>>> 
>>>>>> 
>>>>>> I am surprised that I386_* working and broken.
>>>>>> I would think wordsize and endian is all that matters here.
>>>>>> 
>>>>>> 
>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> 
>>>>>>> 
>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>> I agree if they drop it, we have to.
>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>> but that's not likely.
>>>>>>> A C generating backend also solves this.
>>>>>>> 
>>>>>>> 
>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>> 
>>>>>>> 
>>>>>>> I don't remember about div/mod.
>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>> 
>>>>>>> 
>>>>>>> I'm also not optimizing at all.
>>>>>>> 
>>>>>>> 
>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>> 
>>>>>>> 
>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>> 
>>>>>>> 
>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>> 
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> 
>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>> 
>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>> 
>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>> 
>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>> - my changes to set operations
>>>>>>>>> - my change to div/mod
>>>>>>>>> - Tony's to bit field operations
>>>>>>>>> 
>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>> 
>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>> to keep them if they don't work.
>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>> 
>>>>>>>>> - Jay
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>> 
>>>>>>>>>> - Jay
>>>>>>>>>> 
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>> 
>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>> 
>>>>>>>>>>> - Jay
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Sat May 15 07:57:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 05:57:27 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , ,
	,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , ,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , ,
	,,<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, ,
	,,<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>,
	, , <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
Message-ID: <COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>


I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
And that bit offsets are interpreted differently for big endian and little endian.
? I can NOT confirm that I386_LINUX was broken.
? As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.


I happen to then try a bunch of big endian platforms.


Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
but I think it is fairly easy to come up with structs without bitfields with the "same" layout
across all architectures, at least for a given wordsize/endian.)


I should admit something.
When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
Lately for this reason I've been removing them from code where I can.
Clearly they have a place, where compactness of data is of the prime importance.


It's possible this is just me, that more expert programmers can readily imagine just how
bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
therefore they can determine the layout from glancing at the declaration.


I just can't imagine what would be obvious.
Simple example:

typedef union {
? unsigned AsInt32;
? struct { unsigned a : 1 } Bits;
} T1;


T1 t;
t.Bits.a = 1;


printf("%x\n", t.AsInt32);


prints 1 or 0x80000000 or what?


It could be there are obvious rules, and they are endian dependent, but that otherwise
all ABIs and compilers define them the same.
If that is the case, I think we could get something more "optimal".
However, notice how similar the "optimized" code was.
And we could easily generate that without a bitfield ref.
?Just shift right and and with a constant, instead of shift left and then right.


Could be that the decision is target-dependent as to what is optimal though.


?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:14:54 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>
>
> On 14 May 2010, at 23:10, Jay K wrote:
>
>>
>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>
>> BIT_FIELD_REF considered harmful
>>
>> We should try to use COMPONENT_REF instead.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>> A more accurate one, which shows a problem, is:
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> But I'm still having trouble convincing myself.
>>> I guess the second might give you the 10th bit.
>>> Er, the 9th.
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>>
>>> a = 1 << 9;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> 1 0
>>> 0 1
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>
>>>> Er.
>>>> first: a = (a>> 22) & 1;
>>>> second: a = (a << 22)>> 31;
>>>>
>>>> are actually darn close, maybe the same.
>>>> Let's just be lame and test in C:
>>>>
>>>> #include
>>>> int main()
>>>> {
>>>> unsigned a = ~0;
>>>> unsigned b = (a>> 22) & 1;
>>>> unsigned c = (a << 22)>> 31;
>>>> printf("%x %x\n", b, c);
>>>> return 0;
>>>> }
>>>>
>>>> both print 1. So I remain a bit uncertain.
>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>> I might dig more before commiting the undo.
>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Tony I think it is your change to extract_mn.
>>>>> Try it with SOLsun for example.
>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>
>>>>>
>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>> 77,78c77,78
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 118,119c118,119
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 197,198c197,198
>>>>> < srl %g1, 21, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 21, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 236,237c236,237
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 273,274c273,274
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>>
>>>>>
>>>>> This is not optimized.
>>>>> They seem equally optimal, but very different.
>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>> srl+and is clearer.
>>>>> I don't remember which of these worked.
>>>>>
>>>>>
>>>>> < srl %g1, 22, %g1
>>>>>
>>>>> < and %g1, 1, %g1
>>>>>
>>>>> ---
>>>>>
>>>>>> sll %g1, 22, %g1
>>>>>
>>>>>> srl %g1, 31, %g1
>>>>>
>>>>>
>>>>>
>>>>> I read the first as:
>>>>> extract bit 22, plus or minus 1
>>>>> vs.
>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>
>>>>>
>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>
>>>>>>>
>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>
>>>>>>>
>>>>>>> I have some extra time today, so, plan:
>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>> work through the others if not
>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>> touch it again, which is fine. :) )
>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>
>>>>>>>
>>>>>>> I am surprised that I386_* working and broken.
>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>
>>>>>>>
>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>> I agree if they drop it, we have to.
>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>> but that's not likely.
>>>>>>>> A C generating backend also solves this.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't remember about div/mod.
>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm also not optimizing at all.
>>>>>>>>
>>>>>>>>
>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>
>>>>>>>>
>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>
>>>>>>>>
>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>
>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>
>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>
>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>> - my changes to set operations
>>>>>>>>>> - my change to div/mod
>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>
>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>
>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 07:58:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 05:58:57 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , ,
	,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , ,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , ,
	,,<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, ,
	,,<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>,
	, , <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
Message-ID: <COL101-W188664168A5CE39254D0F5E6FE0@phx.gbl>


> COMPONENT_REF is difficult because of the lack of type info I think
That's what I thought.
It's unfortunate imho.
We could probably do better fairly easily. ?
? Heck, with the possible major upside of having gdb work? (I don't mean m3gdb).
I'm still bothered by the problem I had on OpenBSD/mips64 where a "bitfield ref" with a high byte offset
was treated incorrectly by the compiler, where a component ref would surely have worked.

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:14:54 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>
>
> On 14 May 2010, at 23:10, Jay K wrote:
>
>>
>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>
>> BIT_FIELD_REF considered harmful
>>
>> We should try to use COMPONENT_REF instead.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>> A more accurate one, which shows a problem, is:
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> But I'm still having trouble convincing myself.
>>> I guess the second might give you the 10th bit.
>>> Er, the 9th.
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>>
>>> a = 1 << 9;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> 1 0
>>> 0 1
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>
>>>> Er.
>>>> first: a = (a>> 22) & 1;
>>>> second: a = (a << 22)>> 31;
>>>>
>>>> are actually darn close, maybe the same.
>>>> Let's just be lame and test in C:
>>>>
>>>> #include
>>>> int main()
>>>> {
>>>> unsigned a = ~0;
>>>> unsigned b = (a>> 22) & 1;
>>>> unsigned c = (a << 22)>> 31;
>>>> printf("%x %x\n", b, c);
>>>> return 0;
>>>> }
>>>>
>>>> both print 1. So I remain a bit uncertain.
>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>> I might dig more before commiting the undo.
>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Tony I think it is your change to extract_mn.
>>>>> Try it with SOLsun for example.
>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>
>>>>>
>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>> 77,78c77,78
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 118,119c118,119
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 197,198c197,198
>>>>> < srl %g1, 21, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 21, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 236,237c236,237
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 273,274c273,274
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>>
>>>>>
>>>>> This is not optimized.
>>>>> They seem equally optimal, but very different.
>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>> srl+and is clearer.
>>>>> I don't remember which of these worked.
>>>>>
>>>>>
>>>>> < srl %g1, 22, %g1
>>>>>
>>>>> < and %g1, 1, %g1
>>>>>
>>>>> ---
>>>>>
>>>>>> sll %g1, 22, %g1
>>>>>
>>>>>> srl %g1, 31, %g1
>>>>>
>>>>>
>>>>>
>>>>> I read the first as:
>>>>> extract bit 22, plus or minus 1
>>>>> vs.
>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>
>>>>>
>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>
>>>>>>>
>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>
>>>>>>>
>>>>>>> I have some extra time today, so, plan:
>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>> work through the others if not
>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>> touch it again, which is fine. :) )
>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>
>>>>>>>
>>>>>>> I am surprised that I386_* working and broken.
>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>
>>>>>>>
>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>> I agree if they drop it, we have to.
>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>> but that's not likely.
>>>>>>>> A C generating backend also solves this.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't remember about div/mod.
>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm also not optimizing at all.
>>>>>>>>
>>>>>>>>
>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>
>>>>>>>>
>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>
>>>>>>>>
>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>
>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>
>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>
>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>> - my changes to set operations
>>>>>>>>>> - my change to div/mod
>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>
>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>
>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 09:03:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 07:03:53 +0000
Subject: [M3devel] random.longint()?
Message-ID: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>


In libm3 there is random number generation.
In libm3 that is code that wants 8 random bytes.
? If integer is 4 bytes, it calls random.integer() twice, else if it is 8, once.

It seems natural that we should provide random.longint()?

And then the other code can just use it?

Someone can look into the random number generator and
?- make sure it is actually "correct" for 64bit integer?
?- and if so, change the lowest level to use LONGINT
?? and layer integer over it? -- not sure how, presumably
?? taking only the lower 32bits loses too much randomness?


This is what I get for looking into why we are ever asked to extract 0 bits..

"Everywhere I look, I see bugs." (topic of a separate mail)

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Sat May 15 09:08:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 07:08:03 +0000
Subject: [M3devel] libm3/Swap?
Message-ID: <COL101-W58DAAF4635345A955820B5E6FE0@phx.gbl>


libm3/.../swap.m3:


FROM Word IMPORT Or, And, Not, LeftShift, RightShift, Extract;


CONST
? B0 = 16_FF;
? B1 = 16_FF00;
? B2 = 16_FF0000;
? B3 = 16_FF000000;


? (* These will all be zero on machines with BYTESIZE(INTEGER) = 32 *)
? B4 = LeftShift(B3, 8);
? B5 = LeftShift(B4, 8);
? B6 = LeftShift(B5, 8);
? B7 = LeftShift(B6, 8);

CONST SignExt32 = ARRAY [0..1] OF Word.T {0, Not(16_FFFFFFFF)};

(* Swaps the lower 4 bytes of i *)
PROCEDURE Swap4 (i: Int32): Int32 =
? BEGIN
??? IF BYTESIZE(INTEGER) = 4 THEN
????? RETURN Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
??????????????? Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24)));
??? ELSIF BYTESIZE(INTEGER) = 8 THEN
????? RETURN
??????? Or(SignExt32[Extract(i, 7, 1)],
?????????? Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
????????????? Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24))));
??? ELSE
????? RAISE Failure;
??? END;
? END Swap4;


What is the meaning of the 7?
? In Extract(i, 7, 1)?
Presumably it should be 63??
I guess I'll write a test..


Is there a better idiom that doesn't expose? architectures to compile code for other word sizes?
Maybe fork the file and include_dir(WORD_SIZE)?
?Like is done in m3core/src/C?
?

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 11:24:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 09:24:02 +0000
Subject: [M3devel] libm3/Swap?
Message-ID: <COL101-W64EAAFCE37D8755D457662E6FE0@phx.gbl>


Oh I see, it is sign extending the result, not copying the sign from the original.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: libm3/Swap?
> Date: Sat, 15 May 2010 07:08:03 +0000
>
>
> libm3/.../swap.m3:
>
>
> FROM Word IMPORT Or, And, Not, LeftShift, RightShift, Extract;
>
>
> CONST
>   B0 = 16_FF;
>   B1 = 16_FF00;
>   B2 = 16_FF0000;
>   B3 = 16_FF000000;
>
>
>   (* These will all be zero on machines with BYTESIZE(INTEGER) = 32 *)
>   B4 = LeftShift(B3, 8);
>   B5 = LeftShift(B4, 8);
>   B6 = LeftShift(B5, 8);
>   B7 = LeftShift(B6, 8);
>
> CONST SignExt32 = ARRAY [0..1] OF Word.T {0, Not(16_FFFFFFFF)};
>
> (* Swaps the lower 4 bytes of i *)
> PROCEDURE Swap4 (i: Int32): Int32 =
>   BEGIN
>     IF BYTESIZE(INTEGER) = 4 THEN
>       RETURN Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
>                 Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24)));
>     ELSIF BYTESIZE(INTEGER) = 8 THEN
>       RETURN
>         Or(SignExt32[Extract(i, 7, 1)],
>            Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
>               Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24))));
>     ELSE
>       RAISE Failure;
>     END;
>   END Swap4;
>
>
> What is the meaning of the 7?
>   In Extract(i, 7, 1)?
> Presumably it should be 63??
> I guess I'll write a test..
>
>
> Is there a better idiom that doesn't expose  architectures to compile code for other word sizes?
> Maybe fork the file and include_dir(WORD_SIZE)?
>  Like is done in m3core/src/C?
>
>
>  - Jay
>
 		 	   		  

From hosking at cs.purdue.edu  Sat May 15 18:36:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 12:36:25 -0400
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>
Message-ID: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>

I hesitate to slow down the default implementation of random by using LONGINT (slow) instead of INTEGER (fast).

On 15 May 2010, at 03:03, Jay K wrote:

> 
> In libm3 there is random number generation.
> In libm3 that is code that wants 8 random bytes.
>   If integer is 4 bytes, it calls random.integer() twice, else if it is 8, once.
> 
> It seems natural that we should provide random.longint()?
> 
> And then the other code can just use it?
> 
> Someone can look into the random number generator and
>  - make sure it is actually "correct" for 64bit integer?
>  - and if so, change the lowest level to use LONGINT
>    and layer integer over it? -- not sure how, presumably
>    taking only the lower 32bits loses too much randomness?
> 
> 
> This is what I get for looking into why we are ever asked to extract 0 bits..
> 
> "Everywhere I look, I see bugs." (topic of a separate mail)
> 
>  - Jay
> 
> 		 	   		  



From jay.krell at cornell.edu  Sun May 16 01:22:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 23:22:42 +0000
Subject: [M3devel] random.longint()?
In-Reply-To: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>,
	<DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
Message-ID: <COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>


Fair enough. I guess random.longint() could just call random.integer() twice, or clients could, existing situation, do nothing.

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 12:36:25 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] random.longint()?
>
> I hesitate to slow down the default implementation of random by using LONGINT (slow) instead of INTEGER (fast).
>
> On 15 May 2010, at 03:03, Jay K wrote:
>
>>
>> In libm3 there is random number generation.
>> In libm3 that is code that wants 8 random bytes.
>> If integer is 4 bytes, it calls random.integer() twice, else if it is 8, once.
>>
>> It seems natural that we should provide random.longint()?
>>
>> And then the other code can just use it?
>>
>> Someone can look into the random number generator and
>> - make sure it is actually "correct" for 64bit integer?
>> - and if so, change the lowest level to use LONGINT
>> and layer integer over it? -- not sure how, presumably
>> taking only the lower 32bits loses too much randomness?
>>
>>
>> This is what I get for looking into why we are ever asked to extract 0 bits..
>>
>> "Everywhere I look, I see bugs." (topic of a separate mail)
>>
>> - Jay
>>
>>
>
 		 	   		  

From rodney_bates at lcwb.coop  Sun May 16 03:59:18 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 15 May 2010 20:59:18 -0500
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
 SPARC64_SOLARIS)
In-Reply-To: <COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , , ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , , ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, , ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
	<COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>
Message-ID: <4BEF5176.5020503@lcwb.coop>



Jay K wrote:
> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
> And that bit offsets are interpreted differently for big endian and little endian.
>   I can NOT confirm that I386_LINUX was broken.
>   As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
> 
> 
> I happen to then try a bunch of big endian platforms.
> 
> 
> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
> across all architectures, at least for a given wordsize/endian.)
> 
> 
> I should admit something.
> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
> Lately for this reason I've been removing them from code where I can.
> Clearly they have a place, where compactness of data is of the prime importance.
> 
> 
> It's possible this is just me, that more expert programmers can readily imagine just how
> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
> therefore they can determine the layout from glancing at the declaration.
> 

According to my C '99 standard, just about everything about bit field layout is
implementation-defined, except for the bit count of each field.  Harbison and
Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
using bit-twiddling operators instead of bit fields.  Failing that, they recommend
doing experiments with your particular compiler to verify your assumptions.  Obviously
not possible for portable code.

They do suggest that the fields will likely be laid out right-to-left on a little-endian
machine and conversely.  But even there, it matters what size of "unit" is laid out
this way (a native word, for example) before moving on to the next unit, and that
is also implementation-defined.


> 
> I just can't imagine what would be obvious.
> Simple example:
> 
> typedef union {
>   unsigned AsInt32;
>   struct { unsigned a : 1 } Bits;
> } T1;
> 
> 
> T1 t;
> t.Bits.a = 1;
> 
> 
> printf("%x\n", t.AsInt32);
> 
> 
> prints 1 or 0x80000000 or what?
> 
> 
> It could be there are obvious rules, and they are endian dependent, but that otherwise
> all ABIs and compilers define them the same.
> If that is the case, I think we could get something more "optimal".
> However, notice how similar the "optimized" code was.
> And we could easily generate that without a bitfield ref.
>  Just shift right and and with a constant, instead of shift left and then right.
> 
> 
> Could be that the decision is target-dependent as to what is optimal though.
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 00:14:54 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>
>>
>> On 14 May 2010, at 23:10, Jay K wrote:
>>
>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>
>>> BIT_FIELD_REF considered harmful
>>>
>>> We should try to use COMPONENT_REF instead.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>> A more accurate one, which shows a problem, is:
>>>>
>>>> #include
>>>>
>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>
>>>> int main()
>>>> {
>>>> unsigned a = 1 << 22;
>>>> printf("%x %x\n", F1(a), F2(a));
>>>> return 0;
>>>> }
>>>>
>>>> But I'm still having trouble convincing myself.
>>>> I guess the second might give you the 10th bit.
>>>> Er, the 9th.
>>>>
>>>> #include
>>>>
>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>
>>>> int main()
>>>> {
>>>> unsigned a = 1 << 22;
>>>> printf("%x %x\n", F1(a), F2(a));
>>>>
>>>> a = 1 << 9;
>>>> printf("%x %x\n", F1(a), F2(a));
>>>> return 0;
>>>> }
>>>>
>>>> 1 0
>>>> 0 1
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>> Er.
>>>>> first: a = (a>> 22) & 1;
>>>>> second: a = (a << 22)>> 31;
>>>>>
>>>>> are actually darn close, maybe the same.
>>>>> Let's just be lame and test in C:
>>>>>
>>>>> #include
>>>>> int main()
>>>>> {
>>>>> unsigned a = ~0;
>>>>> unsigned b = (a>> 22) & 1;
>>>>> unsigned c = (a << 22)>> 31;
>>>>> printf("%x %x\n", b, c);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> both print 1. So I remain a bit uncertain.
>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>> I might dig more before commiting the undo.
>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Tony I think it is your change to extract_mn.
>>>>>> Try it with SOLsun for example.
>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>
>>>>>>
>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>> 77,78c77,78
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 118,119c118,119
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 197,198c197,198
>>>>>> < srl %g1, 21, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 21, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 236,237c236,237
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 273,274c273,274
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>>
>>>>>>
>>>>>> This is not optimized.
>>>>>> They seem equally optimal, but very different.
>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>> srl+and is clearer.
>>>>>> I don't remember which of these worked.
>>>>>>
>>>>>>
>>>>>> < srl %g1, 22, %g1
>>>>>>
>>>>>> < and %g1, 1, %g1
>>>>>>
>>>>>> ---
>>>>>>
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>>
>>>>>>
>>>>>> I read the first as:
>>>>>> extract bit 22, plus or minus 1
>>>>>> vs.
>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>
>>>>>>
>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>
>>>>>>>>
>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>
>>>>>>>>
>>>>>>>> I have some extra time today, so, plan:
>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>> work through the others if not
>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>> touch it again, which is fine. :) )
>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>
>>>>>>>>
>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>
>>>>>>>>
>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>> but that's not likely.
>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't remember about div/mod.
>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>
>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>
>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>
>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>
>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>
>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>
>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>
>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>
>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>  		 	   		  


From hendrik at topoi.pooq.com  Sun May 16 01:05:51 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 15 May 2010 19:05:51 -0400
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
References: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
	<COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
Message-ID: <20100515230551.GA24444@topoi.pooq.com>

On Sat, May 15, 2010 at 11:22:42PM +0000, Jay K wrote:
> 
> Fair enough. I guess random.longint() could just call random.integer() twice, or clients could, existing situation, do nothing.

Just how many bits of state does the random number generator have?

-- hendrik


From jay.krell at cornell.edu  Sun May 16 06:36:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 16 May 2010 04:36:21 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
 SPARC64_SOLARIS)
In-Reply-To: <4BEF5176.5020503@lcwb.coop>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , ,
	,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , ,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , ,
	,,<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , ,
	,,<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, ,
	,,<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>,
	, , <COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>, ,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>, ,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>,
	<COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>,
	<4BEF5176.5020503@lcwb.coop>
Message-ID: <COL101-W228E73F7491802AFD3D41AE6FF0@phx.gbl>


> They do suggest that the fields will likely be laid out right-to-left
> on a little-endian machine and conversely.  But even there, it matters
> what size of "unit" is laid out this way (a native word, for example)
> before moving on to the next unit, and that is also implementation-defined.
 
This is what I was alluding to.
Even though the rules are explicitly compiler-dependent, it could be
that to all compiler writers, such as their shared mindset may be,
there are fairly obvious rules to adopt
and they pretty much all adopt the same ones. I don't know.

Not "all compilers", but "gcc on all platforms".

I suspect that if we said like:
#if TARGET_BIG_ENDIAN /* or !TARGET_LITTLE_ENDIAN, one of these probably exists */
  m = TYPE_PRECISION(t) - m.
#endif

it'd work.


Anyway, I put the code back.


It would also be a good idea to consistently used bitfields for all insert/extract
forms, instead of just one extract form. That would provide consistency.
But we also use extract in other places, e.g. division.
 So consistency between insert and extract isn't actually sufficient.


We do use bitfields in an odd way -- for all loads and stores,
that either have a non-zero offset or that do a type conversion,
and it bugs me.


There is something in gcc that decides if you are offseting
more than a word into something only a word size, throw out the offset,
or somesuch. OpenBSD/mips64 used to incorrectly access all "globals".
"Globals" are defined by parse.c as just a block of memory
with a name for its start, and..we don't know the size, so before
we said it is arbitrarily small, like a word, as a workaround I
declare that it is a arbitrarily less small:


static void
m3cg_declare_segment (void)
{
...
  /* we really don't have an idea of what the type of this var is; let's try
     to put something that will be good enough for all the uses of this var we
     are going to see before we have a bind_segment. Use a large size so that
     gcc doesn't think it fits in a register, so that loads out of it do get
     their offsets applied. */
  TREE_TYPE (v)
    = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);
  layout_decl (v, BIGGEST_ALIGNMENT);


We do actually know the size though.
The thing could be declared to be a record with typed fields
 and we could use "component refs", except we don't bother
 passing enough information along.
It's related to what Tony and I said yesterday.


(OpenBSD/mips64 isn't known to fully work anyway.
But MIPS is making a comeback, see:
http://www.openbsd.org/loongson.html
http://www.lemote.com/en/products/all-in-one/2010/0311/122.html
http://www.lemote.com/en/products/Notebook/2010/0310/112.html
etc.
)

?- Jay

----------------------------------------
> Date: Sat, 15 May 2010 20:59:18 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
>
> Jay K wrote:
>> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
>> And that bit offsets are interpreted differently for big endian and little endian.
>> I can NOT confirm that I386_LINUX was broken.
>> As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
>>
>>
>> I happen to then try a bunch of big endian platforms.
>>
>>
>> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
>> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
>> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
>> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
>> across all architectures, at least for a given wordsize/endian.)
>>
>>
>> I should admit something.
>> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
>> Lately for this reason I've been removing them from code where I can.
>> Clearly they have a place, where compactness of data is of the prime importance.
>>
>>
>> It's possible this is just me, that more expert programmers can readily imagine just how
>> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
>> therefore they can determine the layout from glancing at the declaration.
>>
>
> According to my C '99 standard, just about everything about bit field layout is
> implementation-defined, except for the bit count of each field. Harbison and
> Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
> using bit-twiddling operators instead of bit fields. Failing that, they recommend
> doing experiments with your particular compiler to verify your assumptions. Obviously
> not possible for portable code.
>
> They do suggest that the fields will likely be laid out right-to-left on a little-endian
> machine and conversely. But even there, it matters what size of "unit" is laid out
> this way (a native word, for example) before moving on to the next unit, and that
> is also implementation-defined.
>
>
>>
>> I just can't imagine what would be obvious.
>> Simple example:
>>
>> typedef union {
>> unsigned AsInt32;
>> struct { unsigned a : 1 } Bits;
>> } T1;
>>
>>
>> T1 t;
>> t.Bits.a = 1;
>>
>>
>> printf("%x\n", t.AsInt32);
>>
>>
>> prints 1 or 0x80000000 or what?
>>
>>
>> It could be there are obvious rules, and they are endian dependent, but that otherwise
>> all ABIs and compilers define them the same.
>> If that is the case, I think we could get something more "optimal".
>> However, notice how similar the "optimized" code was.
>> And we could easily generate that without a bitfield ref.
>> Just shift right and and with a constant, instead of shift left and then right.
>>
>>
>> Could be that the decision is target-dependent as to what is optimal though.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 00:14:54 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>>
>>>
>>> On 14 May 2010, at 23:10, Jay K wrote:
>>>
>>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>>
>>>> BIT_FIELD_REF considered harmful
>>>>
>>>> We should try to use COMPONENT_REF instead.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>>> A more accurate one, which shows a problem, is:
>>>>>
>>>>> #include
>>>>>
>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>
>>>>> int main()
>>>>> {
>>>>> unsigned a = 1 << 22;
>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>> return 0;
>>>>> }
>>>>>
>>>>> But I'm still having trouble convincing myself.
>>>>> I guess the second might give you the 10th bit.
>>>>> Er, the 9th.
>>>>>
>>>>> #include
>>>>>
>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>
>>>>> int main()
>>>>> {
>>>>> unsigned a = 1 << 22;
>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>
>>>>> a = 1 << 9;
>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>> return 0;
>>>>> }
>>>>>
>>>>> 1 0
>>>>> 0 1
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>> Er.
>>>>>> first: a = (a>> 22) & 1;
>>>>>> second: a = (a << 22)>> 31;
>>>>>>
>>>>>> are actually darn close, maybe the same.
>>>>>> Let's just be lame and test in C:
>>>>>>
>>>>>> #include
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = ~0;
>>>>>> unsigned b = (a>> 22) & 1;
>>>>>> unsigned c = (a << 22)>> 31;
>>>>>> printf("%x %x\n", b, c);
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> both print 1. So I remain a bit uncertain.
>>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>>> I might dig more before commiting the undo.
>>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> Tony I think it is your change to extract_mn.
>>>>>>> Try it with SOLsun for example.
>>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>>
>>>>>>>
>>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>>> 77,78c77,78
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 118,119c118,119
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 197,198c197,198
>>>>>>> < srl %g1, 21, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 21, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 236,237c236,237
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 273,274c273,274
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>>
>>>>>>>
>>>>>>> This is not optimized.
>>>>>>> They seem equally optimal, but very different.
>>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>>> srl+and is clearer.
>>>>>>> I don't remember which of these worked.
>>>>>>>
>>>>>>>
>>>>>>> < srl %g1, 22, %g1
>>>>>>>
>>>>>>> < and %g1, 1, %g1
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>>
>>>>>>>
>>>>>>> I read the first as:
>>>>>>> extract bit 22, plus or minus 1
>>>>>>> vs.
>>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>>
>>>>>>>
>>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have some extra time today, so, plan:
>>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>>> work through the others if not
>>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>>> touch it again, which is fine. :) )
>>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>>> but that's not likely.
>>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't remember about div/mod.
>>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>>
>>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>>
>>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>>
>>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>>
>>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>>
>>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>>
>>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>
 		 	   		  

From rodney_bates at lcwb.coop  Sun May 16 19:53:13 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 16 May 2010 12:53:13 -0500
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
 SPARC64_SOLARIS)
In-Reply-To: <COL101-W228E73F7491802AFD3D41AE6FF0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , , , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , , , ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , , , ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, , , ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, , ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>, ,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>, ,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>,
	<COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>,
	<4BEF5176.5020503@lcwb.coop>
	<COL101-W228E73F7491802AFD3D41AE6FF0@phx.gbl>
Message-ID: <4BF03109.1050704@lcwb.coop>



Jay K wrote:
>> They do suggest that the fields will likely be laid out right-to-left
>> on a little-endian machine and conversely.  But even there, it matters
>> what size of "unit" is laid out this way (a native word, for example)
>> before moving on to the next unit, and that is also implementation-defined.
>  
> This is what I was alluding to.
> Even though the rules are explicitly compiler-dependent, it could be
> that to all compiler writers, such as their shared mindset may be,
> there are fairly obvious rules to adopt
> and they pretty much all adopt the same ones. I don't know.
> 
> Not "all compilers", but "gcc on all platforms".
> 
> I suspect that if we said like:
> #if TARGET_BIG_ENDIAN /* or !TARGET_LITTLE_ENDIAN, one of these probably exists */
>   m = TYPE_PRECISION(t) - m.
> #endif
> 
> it'd work.
> 
> 
> Anyway, I put the code back.
> 
> 
> It would also be a good idea to consistently used bitfields for all insert/extract
> forms, instead of just one extract form. That would provide consistency.
> But we also use extract in other places, e.g. division.
>  So consistency between insert and extract isn't actually sufficient.

Ah, are you talking about bit field _operators_ in the intermediate form
generated by parse.c to gcc?  These could well be a different animal
from C source code bit fields.  Or perhaps the C front end does a direct
translation, but gcc has well-defined semantics for them.  I would expect
these would follow a consistent pattern, for gcc.  Might have to do some
heavy code reading to infer it.

> 
> 
> We do use bitfields in an odd way -- for all loads and stores,
> that either have a non-zero offset or that do a type conversion,
> and it bugs me.
> 
> 
> There is something in gcc that decides if you are offseting
> more than a word into something only a word size, throw out the offset,
> or somesuch. OpenBSD/mips64 used to incorrectly access all "globals".
> "Globals" are defined by parse.c as just a block of memory
> with a name for its start, and..we don't know the size, so before
> we said it is arbitrarily small, like a word, as a workaround I
> declare that it is a arbitrarily less small:
> 
> 
> static void
> m3cg_declare_segment (void)
> {
> ...
>   /* we really don't have an idea of what the type of this var is; let's try
>      to put something that will be good enough for all the uses of this var we
>      are going to see before we have a bind_segment. Use a large size so that
>      gcc doesn't think it fits in a register, so that loads out of it do get
>      their offsets applied. */
>   TREE_TYPE (v)
>     = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);
>   layout_decl (v, BIGGEST_ALIGNMENT);
> 
> 
> We do actually know the size though.
> The thing could be declared to be a record with typed fields
>  and we could use "component refs", except we don't bother
>  passing enough information along.
> It's related to what Tony and I said yesterday.
> 
> 
> (OpenBSD/mips64 isn't known to fully work anyway.
> But MIPS is making a comeback, see:
> http://www.openbsd.org/loongson.html
> http://www.lemote.com/en/products/all-in-one/2010/0311/122.html
> http://www.lemote.com/en/products/Notebook/2010/0310/112.html
> etc.
> )
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Sat, 15 May 2010 20:59:18 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>>
>> Jay K wrote:
>>> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
>>> And that bit offsets are interpreted differently for big endian and little endian.
>>> I can NOT confirm that I386_LINUX was broken.
>>> As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
>>>
>>>
>>> I happen to then try a bunch of big endian platforms.
>>>
>>>
>>> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
>>> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
>>> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
>>> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
>>> across all architectures, at least for a given wordsize/endian.)
>>>
>>>
>>> I should admit something.
>>> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
>>> Lately for this reason I've been removing them from code where I can.
>>> Clearly they have a place, where compactness of data is of the prime importance.
>>>
>>>
>>> It's possible this is just me, that more expert programmers can readily imagine just how
>>> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
>>> therefore they can determine the layout from glancing at the declaration.
>>>
>> According to my C '99 standard, just about everything about bit field layout is
>> implementation-defined, except for the bit count of each field. Harbison and
>> Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
>> using bit-twiddling operators instead of bit fields. Failing that, they recommend
>> doing experiments with your particular compiler to verify your assumptions. Obviously
>> not possible for portable code.
>>
>> They do suggest that the fields will likely be laid out right-to-left on a little-endian
>> machine and conversely. But even there, it matters what size of "unit" is laid out
>> this way (a native word, for example) before moving on to the next unit, and that
>> is also implementation-defined.
>>
>>
>>> I just can't imagine what would be obvious.
>>> Simple example:
>>>
>>> typedef union {
>>> unsigned AsInt32;
>>> struct { unsigned a : 1 } Bits;
>>> } T1;
>>>
>>>
>>> T1 t;
>>> t.Bits.a = 1;
>>>
>>>
>>> printf("%x\n", t.AsInt32);
>>>
>>>
>>> prints 1 or 0x80000000 or what?
>>>
>>>
>>> It could be there are obvious rules, and they are endian dependent, but that otherwise
>>> all ABIs and compilers define them the same.
>>> If that is the case, I think we could get something more "optimal".
>>> However, notice how similar the "optimized" code was.
>>> And we could easily generate that without a bitfield ref.
>>> Just shift right and and with a constant, instead of shift left and then right.
>>>
>>>
>>> Could be that the decision is target-dependent as to what is optimal though.
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 00:14:54 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>>>
>>>>
>>>> On 14 May 2010, at 23:10, Jay K wrote:
>>>>
>>>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>>>
>>>>> BIT_FIELD_REF considered harmful
>>>>>
>>>>> We should try to use COMPONENT_REF instead.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>>>> A more accurate one, which shows a problem, is:
>>>>>>
>>>>>> #include
>>>>>>
>>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = 1 << 22;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> But I'm still having trouble convincing myself.
>>>>>> I guess the second might give you the 10th bit.
>>>>>> Er, the 9th.
>>>>>>
>>>>>> #include
>>>>>>
>>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = 1 << 22;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>>
>>>>>> a = 1 << 9;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> 1 0
>>>>>> 0 1
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>> Er.
>>>>>>> first: a = (a>> 22) & 1;
>>>>>>> second: a = (a << 22)>> 31;
>>>>>>>
>>>>>>> are actually darn close, maybe the same.
>>>>>>> Let's just be lame and test in C:
>>>>>>>
>>>>>>> #include
>>>>>>> int main()
>>>>>>> {
>>>>>>> unsigned a = ~0;
>>>>>>> unsigned b = (a>> 22) & 1;
>>>>>>> unsigned c = (a << 22)>> 31;
>>>>>>> printf("%x %x\n", b, c);
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> both print 1. So I remain a bit uncertain.
>>>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>>>> I might dig more before commiting the undo.
>>>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> Tony I think it is your change to extract_mn.
>>>>>>>> Try it with SOLsun for example.
>>>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>>>
>>>>>>>>
>>>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>>>> 77,78c77,78
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 118,119c118,119
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 197,198c197,198
>>>>>>>> < srl %g1, 21, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 21, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 236,237c236,237
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 273,274c273,274
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>>
>>>>>>>>
>>>>>>>> This is not optimized.
>>>>>>>> They seem equally optimal, but very different.
>>>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>>>> srl+and is clearer.
>>>>>>>> I don't remember which of these worked.
>>>>>>>>
>>>>>>>>
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>>
>>>>>>>> < and %g1, 1, %g1
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>>
>>>>>>>> I read the first as:
>>>>>>>> extract bit 22, plus or minus 1
>>>>>>>> vs.
>>>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>>>
>>>>>>>>
>>>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have some extra time today, so, plan:
>>>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>>>> work through the others if not
>>>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>>>> touch it again, which is fine. :) )
>>>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>>>> but that's not likely.
>>>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't remember about div/mod.
>>>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>>>
>>>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>  		 	   		  


From hendrik at topoi.pooq.com  Wed May 19 22:54:11 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 19 May 2010 16:54:11 -0400
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
References: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
	<COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
Message-ID: <20100519205411.GA18956@topoi.pooq.com>

On Sat, May 15, 2010 at 11:22:42PM +0000, Jay K wrote:
> 
> Fair enough. I guess random.longint() could just call random.integer() twice, or clients could, existing situation, do nothing.

I don't know how many bits of state the prwudorandom number generator 
uses, but is it has the usual 32 bits, calling random.integer() twice to 
get 64 bits does *not* give properly randome 64-bi strings.

-- hendrik


From dragisha at m3w.org  Thu May 20 12:08:53 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 20 May 2010 12:08:53 +0200
Subject: [M3devel] Linux/ARM? Android?
Message-ID: <1274350133.8902.0.camel@localhost>

As per subject... What is status of Linux/ARM port of Modula-3 and
chances for Android port?
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu May 20 13:47:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 11:47:56 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <1274350133.8902.0.camel@localhost>
References: <1274350133.8902.0.camel@localhost>
Message-ID: <COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>


Status is roughly nowhere.
Chances are not bad though.
There is very little work to do when the system supports posix and gcc supports the system, and that describes a lot of systems.
? Try this: cd scripts/python && ./boot1.py ARM_LINUX 


Give me ssh access to a device?
?Or maybe there is emulator?


I've had a PogoPlug (Linux/ARM) for over a year, haven't touched it.
And some I think Linux/ARM LaCie network drive also.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Thu, 20 May 2010 12:08:53 +0200
> Subject: [M3devel] Linux/ARM? Android?
>
> As per subject... What is status of Linux/ARM port of Modula-3 and
> chances for Android port?
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 13:50:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 11:50:50 +0000
Subject: [M3devel] gcc 4.5.0?
Message-ID: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>


Tony, what is involved in upgrading to gcc 4.5.0?

Import unchanged gcc.4-5.0 to the "gcc-releases" branch?

Merge it to the "gcc" branch?

And then to head?




I mean, you know..there are all the directions out there for managing
external trees, but I think the main missing detail is what
branches/tag names to use to match previous history, and it isn't
immediately clear to me..from, um, reading the history (which imho is
yet another indictment of CVS -- I can't figure out what happened).


I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
But I haven't ever updated it.
e.g. cvsup.


I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
The diffs are quite small.
But I know that's not considered the right way.


(I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)


?- Jay

 		 	   		  

From dragisha at m3w.org  Thu May 20 14:24:32 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 20 May 2010 14:24:32 +0200
Subject: [M3devel] ***SPAM*** RE:  Linux/ARM? Android?
In-Reply-To: <COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
References: <1274350133.8902.0.camel@localhost>
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
Message-ID: <1274358272.8902.2.camel@localhost>

I'll have a HTC Tattoo in a week or so. No problems then for anything.

It does not support pthread_cancel, as far as I know for now. And I
don't think we need it. Nor glibc - it's lib is bionic (didn't check it
yet).

On Thu, 2010-05-20 at 11:47 +0000, Jay K wrote:
> Status is roughly nowhere.
> Chances are not bad though.
> There is very little work to do when the system supports posix and gcc supports the system, and that describes a lot of systems.
>   Try this: cd scripts/python && ./boot1.py ARM_LINUX 
> 
> 
> Give me ssh access to a device?
>  Or maybe there is emulator?
> 
> 
> I've had a PogoPlug (Linux/ARM) for over a year, haven't touched it.
> And some I think Linux/ARM LaCie network drive also.
> 
> 
>  - Jay
> 
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: m3devel at elegosoft.com
> > Date: Thu, 20 May 2010 12:08:53 +0200
> > Subject: [M3devel] Linux/ARM? Android?
> >
> > As per subject... What is status of Linux/ARM port of Modula-3 and
> > chances for Android port?
> > --
> > Dragi?a Duri? 
> >
>  		 	   		  

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



From hosking at cs.purdue.edu  Thu May 20 15:10:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 09:10:03 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>
Message-ID: <76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>

Unfortunately, it has never been as easy as import release, merge to head.  Usually there are many differences that need to be resolved by hand.  But, that is how it should be done.

And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.

As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.

On 20 May 2010, at 07:50, Jay K wrote:

> 
> Tony, what is involved in upgrading to gcc 4.5.0?
> 
> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
> 
> Merge it to the "gcc" branch?
> 
> And then to head?
> 
> 
> 
> 
> I mean, you know..there are all the directions out there for managing
> external trees, but I think the main missing detail is what
> branches/tag names to use to match previous history, and it isn't
> immediately clear to me..from, um, reading the history (which imho is
> yet another indictment of CVS -- I can't figure out what happened).
> 
> 
> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
> But I haven't ever updated it.
> e.g. cvsup.
> 
> 
> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
> The diffs are quite small.
> But I know that's not considered the right way.
> 
> 
> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
> 
> 
>  - Jay
> 
> 		 	   		  



From jay.krell at cornell.edu  Thu May 20 15:12:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 13:12:20 +0000
Subject: [M3devel] ***SPAM*** RE:  Linux/ARM? Android?
In-Reply-To: <1274358272.8902.2.camel@localhost>
References: <1274350133.8902.0.camel@localhost>,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	<1274358272.8902.2.camel@localhost>
Message-ID: <COL101-W48D5715499DCC521AABCB1E6E30@phx.gbl>


If you can provide ssh access to it and a "native" C development environment, I'll have a go at it.
By "native" C development, I mean "official", not necessarily "hosted on the target machine".
If the C development environment is easily acquired, I can do that part. It probably is.
There's a possibility, possibility, we should have separate ARM_LINUX and ARM_ANROID or or ARM_GNU_LINUX or ARM_BIONIC_LINUX or ARM_LINUX_ANDROID or ARM_LINUX_GOOGLE or ARM_GOOGLE or ARM_LINUX_GOOGLE or ARM_GOOGLE_LINUX or ARM_OHSA_LINUX ("open handset aliance?") or such.


In particular, if there jmpbuf sizes are different, then we should.
The "Modula-3 compiler" cares only about: endian, word size, jmpbuf size, basically that's it.
?Alignment too, but they are all the same.
?"Code alignment" too, some of each, for the closure stuff.


If they aren't binary compatible, then we probably should -- just to propagate it out to the naming of packages really.


There is "something" nagging to get out that isn't a "target" or? "platform" but something like a "configuration".
?For example, SOLsun and SOLgnu are the same, except for which C compiler they use to compiler a few files, and for the C-compiler-as-linker-driver.
? They have the same jumpbuf, the same stack walker, they end up with the same #ifs in the C code, at least wrt #if __sun, not #if __GNUC__.


Basically it seems that "platform" = "kernel" + "C library" + processor + "sometimes C compiler/linker" + "Windowing system" + "GUI library" + "file i/o library"
But many of them correlate very very strongly.
"C library" varies -- uclibc, dietlibc, glibc, eglibc, bionic.
file i/o library = posix or win32
threads = pthreads or posix user threads perhaps or win32
?? (ie: we should have separate I386_LINUX_USERTHREADS?)


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 20 May 2010 14:24:32 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ***SPAM*** RE: Linux/ARM? Android?
>
> I'll have a HTC Tattoo in a week or so. No problems then for anything.
>
> It does not support pthread_cancel, as far as I know for now. And I
> don't think we need it. Nor glibc - it's lib is bionic (didn't check it
> yet).
>
> On Thu, 2010-05-20 at 11:47 +0000, Jay K wrote:
>> Status is roughly nowhere.
>> Chances are not bad though.
>> There is very little work to do when the system supports posix and gcc supports the system, and that describes a lot of systems.
>> Try this: cd scripts/python && ./boot1.py ARM_LINUX
>>
>>
>> Give me ssh access to a device?
>> Or maybe there is emulator?
>>
>>
>> I've had a PogoPlug (Linux/ARM) for over a year, haven't touched it.
>> And some I think Linux/ARM LaCie network drive also.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: dragisha at m3w.org
>>> To: m3devel at elegosoft.com
>>> Date: Thu, 20 May 2010 12:08:53 +0200
>>> Subject: [M3devel] Linux/ARM? Android?
>>>
>>> As per subject... What is status of Linux/ARM port of Modula-3 and
>>> chances for Android port?
>>> --
>>> Dragi?a Duri?
>>>
>>
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 15:21:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 13:21:09 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>
Message-ID: <COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>


eh, ok, I'll try that then.


Have you noticed what I did for OpenBSD?
Perhaps easier to just commit those diffs?
In order to facilitate merging?
Tedious either way of course.


What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
?? OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
Largely they aren't relevant, like to c-*.c.
Largely they are trivial. Just configure/makefile snippets.
Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
We apply them during our build, in m3makefile.


Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
And commit with minimal testing instead of a big matrix.


But it bloats the source tree a lot.


I'd also like to somehow reduce how often gmp and mpfr are built.
They are a huge fraction of the time.
And 4.5.0 adds another similar library, mpc.
? "c" for complex numbers..more stuff we don't use...


It seems our main changes are:
? introducing of static chain for nested procedures
? Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
? Or Pascal? I mean..do we have to add our own?

? small hacks to inhibit optimization 


? the little makefile machinery 


Also, have you noticed that 4.5.0 has a "plugin" interface?
Perhaps we can just use that, and just distribute a small .so file.
At least once 4.5.0 is in wide use.


?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 09:10:03 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>
> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>
> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>
> On 20 May 2010, at 07:50, Jay K wrote:
>
>>
>> Tony, what is involved in upgrading to gcc 4.5.0?
>>
>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>
>> Merge it to the "gcc" branch?
>>
>> And then to head?
>>
>>
>>
>>
>> I mean, you know..there are all the directions out there for managing
>> external trees, but I think the main missing detail is what
>> branches/tag names to use to match previous history, and it isn't
>> immediately clear to me..from, um, reading the history (which imho is
>> yet another indictment of CVS -- I can't figure out what happened).
>>
>>
>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>> But I haven't ever updated it.
>> e.g. cvsup.
>>
>>
>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>> The diffs are quite small.
>> But I know that's not considered the right way.
>>
>>
>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>
>>
>> - Jay
>>
>>
>
 		 	   		  

From mika at async.async.caltech.edu  Thu May 20 15:44:37 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 20 May 2010 06:44:37 -0700
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl> 
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>
Message-ID: <20100520134437.D15551A2094@async.async.caltech.edu>


I would be a bit careful here.  Presumably there are a lot of subtypes
of Random.T out there that override methods in various ways...  Layering
longint on top of multiple calls to integer (rather than the other way
around) seems like the safe approach to getting things working.

   Mika

Jay K writes:
>
>In libm3 there is random number generation.
>In libm3 that is code that wants 8 random bytes.
>=A0 If integer is 4 bytes=2C it calls random.integer() twice=2C else if it =
>is 8=2C once.
>
>It seems natural that we should provide random.longint()?
>
>And then the other code can just use it?
>
>Someone can look into the random number generator and
>=A0- make sure it is actually "correct" for 64bit integer?
>=A0- and if so=2C change the lowest level to use LONGINT
>=A0=A0 and layer integer over it? -- not sure how=2C presumably
>=A0=A0 taking only the lower 32bits loses too much randomness?
>
>
>This is what I get for looking into why we are ever asked to extract 0 bits=
>..
>
>"Everywhere I look=2C I see bugs." (topic of a separate mail)
>
>=A0- Jay
>
> 		 	   		  =


From hosking at cs.purdue.edu  Thu May 20 15:54:14 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 09:54:14 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>
Message-ID: <2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>



On 20 May 2010, at 09:21, Jay K wrote:

> 
> eh, ok, I'll try that then.
> 
> 
> Have you noticed what I did for OpenBSD?
> Perhaps easier to just commit those diffs?
> In order to facilitate merging?
> Tedious either way of course.
> 
> 
> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>    OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
> Largely they aren't relevant, like to c-*.c.
> Largely they are trivial. Just configure/makefile snippets.
> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
> We apply them during our build, in m3makefile.
> 
> 
> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
> And commit with minimal testing instead of a big matrix.
> 
> 
> But it bloats the source tree a lot.
> 
> 
> I'd also like to somehow reduce how often gmp and mpfr are built.
> They are a huge fraction of the time.
> And 4.5.0 adds another similar library, mpc.
>   "c" for complex numbers..more stuff we don't use...
> 
> 
> It seems our main changes are:
>   introducing of static chain for nested procedures
>   Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>   Or Pascal? I mean..do we have to add our own?

Yes, we need the support for extracting the static chain for passing with procedure arguments.  Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain).  i.e., they are "static" closures.

>   small hacks to inhibit optimisation

It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.

>   the little makefile machinery 
> 
> 
> Also, have you noticed that 4.5.0 has a "plugin" interface?

Yes, I'd heard about that.

> Perhaps we can just use that, and just distribute a small .so file.

That would be *very* cool.

> At least once 4.5.0 is in wide use.

Right.

> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 20 May 2010 09:10:03 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>> 
>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>> 
>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>> 
>> On 20 May 2010, at 07:50, Jay K wrote:
>> 
>>> 
>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>> 
>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>> 
>>> Merge it to the "gcc" branch?
>>> 
>>> And then to head?
>>> 
>>> 
>>> 
>>> 
>>> I mean, you know..there are all the directions out there for managing
>>> external trees, but I think the main missing detail is what
>>> branches/tag names to use to match previous history, and it isn't
>>> immediately clear to me..from, um, reading the history (which imho is
>>> yet another indictment of CVS -- I can't figure out what happened).
>>> 
>>> 
>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>> But I haven't ever updated it.
>>> e.g. cvsup.
>>> 
>>> 
>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>> The diffs are quite small.
>>> But I know that's not considered the right way.
>>> 
>>> 
>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Thu May 20 16:01:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 14:01:09 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
Message-ID: <COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>


What I meant regarding "static chain" was more like "does gcc already have support that we can use".
Don't any of the other languages need it already?
Ada? Pascal? Maybe the nested C function support?

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 09:54:14 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
>
>
> On 20 May 2010, at 09:21, Jay K wrote:
>
>>
>> eh, ok, I'll try that then.
>>
>>
>> Have you noticed what I did for OpenBSD?
>> Perhaps easier to just commit those diffs?
>> In order to facilitate merging?
>> Tedious either way of course.
>>
>>
>> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>> OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
>> Largely they aren't relevant, like to c-*.c.
>> Largely they are trivial. Just configure/makefile snippets.
>> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
>> We apply them during our build, in m3makefile.
>>
>>
>> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
>> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
>> And commit with minimal testing instead of a big matrix.
>>
>>
>> But it bloats the source tree a lot.
>>
>>
>> I'd also like to somehow reduce how often gmp and mpfr are built.
>> They are a huge fraction of the time.
>> And 4.5.0 adds another similar library, mpc.
>> "c" for complex numbers..more stuff we don't use...
>>
>>
>> It seems our main changes are:
>> introducing of static chain for nested procedures
>> Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>> Or Pascal? I mean..do we have to add our own?
>
> Yes, we need the support for extracting the static chain for passing with procedure arguments. Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain). i.e., they are "static" closures.
>
>> small hacks to inhibit optimisation
>
> It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.
>
>> the little makefile machinery
>>
>>
>> Also, have you noticed that 4.5.0 has a "plugin" interface?
>
> Yes, I'd heard about that.
>
>> Perhaps we can just use that, and just distribute a small .so file.
>
> That would be *very* cool.
>
>> At least once 4.5.0 is in wide use.
>
> Right.
>
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 20 May 2010 09:10:03 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>>>
>>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>>>
>>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>>>
>>> On 20 May 2010, at 07:50, Jay K wrote:
>>>
>>>>
>>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>>>
>>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>>>
>>>> Merge it to the "gcc" branch?
>>>>
>>>> And then to head?
>>>>
>>>>
>>>>
>>>>
>>>> I mean, you know..there are all the directions out there for managing
>>>> external trees, but I think the main missing detail is what
>>>> branches/tag names to use to match previous history, and it isn't
>>>> immediately clear to me..from, um, reading the history (which imho is
>>>> yet another indictment of CVS -- I can't figure out what happened).
>>>>
>>>>
>>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>>> But I haven't ever updated it.
>>>> e.g. cvsup.
>>>>
>>>>
>>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>>> The diffs are quite small.
>>>> But I know that's not considered the right way.
>>>>
>>>>
>>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 16:04:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 14:04:45 +0000
Subject: [M3devel] random.longint()?
In-Reply-To: <20100520134437.D15551A2094@async.async.caltech.edu>
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>,
	<20100520134437.D15551A2094@async.async.caltech.edu>
Message-ID: <COL101-W6248BB81D2C8DF3DF0D94AE6E30@phx.gbl>


I'm just going to leave it alone.
There's already code that checks BITSIZE(INTEGER) and makes one or two calls accordingly.


More interesting probably..but again probably nothing from me..is using modern OS
sources of randomness, entropy, random numbers.


http://www.opengroup.org/onlinepubs/007908799/xsh/drand48.html
http://en.wikipedia.org/wiki/CryptGenRandom


You know..sometimes underlying system doesn't offer much and you do it yourself.
Sometimes the underlying systems catch up..


?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] random.longint()?
> Date: Thu, 20 May 2010 06:44:37 -0700
> From: mika at async.async.caltech.edu
>
>
> I would be a bit careful here. Presumably there are a lot of subtypes
> of Random.T out there that override methods in various ways... Layering
> longint on top of multiple calls to integer (rather than the other way
> around) seems like the safe approach to getting things working.
>
> Mika
>
> Jay K writes:
>>
>>In libm3 there is random number generation.
>>In libm3 that is code that wants 8 random bytes.
>>=A0 If integer is 4 bytes=2C it calls random.integer() twice=2C else if it =
>>is 8=2C once.
>>
>>It seems natural that we should provide random.longint()?
>>
>>And then the other code can just use it?
>>
>>Someone can look into the random number generator and
>>=A0- make sure it is actually "correct" for 64bit integer?
>>=A0- and if so=2C change the lowest level to use LONGINT
>>=A0=A0 and layer integer over it? -- not sure how=2C presumably
>>=A0=A0 taking only the lower 32bits loses too much randomness?
>>
>>
>>This is what I get for looking into why we are ever asked to extract 0 bits=
>>..
>>
>>"Everywhere I look=2C I see bugs." (topic of a separate mail)
>>
>>=A0- Jay
>>
>> =
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 15:59:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 13:59:53 +0000
Subject: [M3devel] limiting .so exports
Message-ID: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>


limiting .so exports
?(and direct binding to symbols in same .so)


FYI:


No clear question here, just a heads up regarding stuff that might be coming.



I'm working on limiting .so exports to only "what they should be".


In particular, given:

INTERFACE Foo;

PROCEDURE Bar();

END Foo.

MODULE Foo;

PROCEDURE F() = BEGIN ... END F;

PROCEDURE Bar() = BEGIN F(); END Bar;

END Foo.


Foo__F should not exported.
Foo__Bar should be.


Today they both would be.
Or at least in the recent past.
?I already made a change in parse.c to reduce things.


However at that level I don't believe we have the needed information.
? (needs investigation)


What I have is that in MxOut.m3, I write out all the symbols in
import_def_syms for modules.
Plus the _M3 and _I3 symbols.


That is most of the work.
However there are missing or non-ideal parts.


In the config files I then transform the list into the format
required by the compiler/linker. I was doing the transform in MxOut.m3
but it was getting to be "too much" work.


You also need to export anything marked <* EXTERNAL *> in interfaces.
I can get that list, however I have been using the "trick" of not
always implementing all EXTERNALs.
Sometimes the C implementation has #ifdefs around it.
So that becomes difficult.


gcc has __attribute__ and #pragma GCC visibility to control things
also, but this seems to conflict with giving a list in a file to
the compiler/linker.


What I have currently is that after compiling any C file, I run
nm on it to get its symbols.


I combine the nm output with the MxOut.m3 output.


Unfortunately that exports more of the C code than intended.
But code that always was exported -- like all of ThreadPThread.c.


As well something I haven't fixed yet is that lowercase interface
contents should not be exported, only capital Interface.


The list would be presented with
? GNU ld: --version-script
? Sun ld: -M for mapfile
? Mac ld: --export-symbol-list


Sun ld and GNU ld accept roughly the same input.


I'm not sure how these two mechanisms compare.
It could be that it is better to use source/parse.c-level "visibility"
and not present the lists to the linker.
In particular that allows for not exporting more of the C.


I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.


The "list" approach should probably at least be used on NT/Cygwin.
Currently we export everything by mklib enumerating the symbols.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Thu May 20 16:50:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 10:50:42 -0400
Subject: [M3devel] limiting .so exports
In-Reply-To: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>
References: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>
Message-ID: <4940E887-0077-434D-A63E-88D76D6E76DA@cs.purdue.edu>

Can we not just push more information through to the back-ends for import_global/import_procedure?  The front-end would need to know where it found the import (in the local package or in another imported package) but all that information would be derivable from m3linker wouldn't it?




On 20 May 2010, at 09:59, Jay K wrote:

> 
> limiting .so exports
>  (and direct binding to symbols in same .so)
> 
> 
> FYI:
> 
> 
> No clear question here, just a heads up regarding stuff that might be coming.
> 
> 
> 
> I'm working on limiting .so exports to only "what they should be".
> 
> 
> In particular, given:
> 
> INTERFACE Foo;
> 
> PROCEDURE Bar();
> 
> END Foo.
> 
> MODULE Foo;
> 
> PROCEDURE F() = BEGIN ... END F;
> 
> PROCEDURE Bar() = BEGIN F(); END Bar;
> 
> END Foo.
> 
> 
> Foo__F should not exported.
> Foo__Bar should be.
> 
> 
> Today they both would be.
> Or at least in the recent past.
>  I already made a change in parse.c to reduce things.
> 
> 
> However at that level I don't believe we have the needed information.
>   (needs investigation)
> 
> 
> What I have is that in MxOut.m3, I write out all the symbols in
> import_def_syms for modules.
> Plus the _M3 and _I3 symbols.
> 
> 
> That is most of the work.
> However there are missing or non-ideal parts.
> 
> 
> In the config files I then transform the list into the format
> required by the compiler/linker. I was doing the transform in MxOut.m3
> but it was getting to be "too much" work.
> 
> 
> You also need to export anything marked <* EXTERNAL *> in interfaces.
> I can get that list, however I have been using the "trick" of not
> always implementing all EXTERNALs.
> Sometimes the C implementation has #ifdefs around it.
> So that becomes difficult.
> 
> 
> gcc has __attribute__ and #pragma GCC visibility to control things
> also, but this seems to conflict with giving a list in a file to
> the compiler/linker.
> 
> 
> What I have currently is that after compiling any C file, I run
> nm on it to get its symbols.
> 
> 
> I combine the nm output with the MxOut.m3 output.
> 
> 
> Unfortunately that exports more of the C code than intended.
> But code that always was exported -- like all of ThreadPThread.c.
> 
> 
> As well something I haven't fixed yet is that lowercase interface
> contents should not be exported, only capital Interface.
> 
> 
> The list would be presented with
>   GNU ld: --version-script
>   Sun ld: -M for mapfile
>   Mac ld: --export-symbol-list
> 
> 
> Sun ld and GNU ld accept roughly the same input.
> 
> 
> I'm not sure how these two mechanisms compare.
> It could be that it is better to use source/parse.c-level "visibility"
> and not present the lists to the linker.
> In particular that allows for not exporting more of the C.
> 
> 
> I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.
> 
> 
> The "list" approach should probably at least be used on NT/Cygwin.
> Currently we export everything by mklib enumerating the symbols.
> 
> 
>  - Jay
> 		 	   		  



From hosking at cs.purdue.edu  Thu May 20 16:52:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 10:52:03 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
Message-ID: <DAB881D4-AB78-4C8D-842A-3A9448AA5B6A@cs.purdue.edu>

Yes, we do make use of some of gcc's static chain machinery.  We just avoid the need for the trampolines that gcc uses because we need a reified static chain that is otherwise computed in the trampoline on the way to calling a nested procedure.

On 20 May 2010, at 10:01, Jay K wrote:

> 
> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
> Don't any of the other languages need it already?
> Ada? Pascal? Maybe the nested C function support?
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 20 May 2010 09:54:14 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> 
>> 
>> On 20 May 2010, at 09:21, Jay K wrote:
>> 
>>> 
>>> eh, ok, I'll try that then.
>>> 
>>> 
>>> Have you noticed what I did for OpenBSD?
>>> Perhaps easier to just commit those diffs?
>>> In order to facilitate merging?
>>> Tedious either way of course.
>>> 
>>> 
>>> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>>> OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
>>> Largely they aren't relevant, like to c-*.c.
>>> Largely they are trivial. Just configure/makefile snippets.
>>> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
>>> We apply them during our build, in m3makefile.
>>> 
>>> 
>>> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
>>> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
>>> And commit with minimal testing instead of a big matrix.
>>> 
>>> 
>>> But it bloats the source tree a lot.
>>> 
>>> 
>>> I'd also like to somehow reduce how often gmp and mpfr are built.
>>> They are a huge fraction of the time.
>>> And 4.5.0 adds another similar library, mpc.
>>> "c" for complex numbers..more stuff we don't use...
>>> 
>>> 
>>> It seems our main changes are:
>>> introducing of static chain for nested procedures
>>> Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>>> Or Pascal? I mean..do we have to add our own?
>> 
>> Yes, we need the support for extracting the static chain for passing with procedure arguments. Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain). i.e., they are "static" closures.
>> 
>>> small hacks to inhibit optimisation
>> 
>> It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.
>> 
>>> the little makefile machinery
>>> 
>>> 
>>> Also, have you noticed that 4.5.0 has a "plugin" interface?
>> 
>> Yes, I'd heard about that.
>> 
>>> Perhaps we can just use that, and just distribute a small .so file.
>> 
>> That would be *very* cool.
>> 
>>> At least once 4.5.0 is in wide use.
>> 
>> Right.
>> 
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Thu, 20 May 2010 09:10:03 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>> 
>>>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>>>> 
>>>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>>>> 
>>>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>>>> 
>>>> On 20 May 2010, at 07:50, Jay K wrote:
>>>> 
>>>>> 
>>>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>>>> 
>>>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>>>> 
>>>>> Merge it to the "gcc" branch?
>>>>> 
>>>>> And then to head?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> I mean, you know..there are all the directions out there for managing
>>>>> external trees, but I think the main missing detail is what
>>>>> branches/tag names to use to match previous history, and it isn't
>>>>> immediately clear to me..from, um, reading the history (which imho is
>>>>> yet another indictment of CVS -- I can't figure out what happened).
>>>>> 
>>>>> 
>>>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>>>> But I haven't ever updated it.
>>>>> e.g. cvsup.
>>>>> 
>>>>> 
>>>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>>>> The diffs are quite small.
>>>>> But I know that's not considered the right way.
>>>>> 
>>>>> 
>>>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Thu May 20 17:28:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 15:28:19 +0000
Subject: [M3devel] limiting .so exports
In-Reply-To: <4940E887-0077-434D-A63E-88D76D6E76DA@cs.purdue.edu>
References: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>,
	<4940E887-0077-434D-A63E-88D76D6E76DA@cs.purdue.edu>
Message-ID: <COL101-W51B9331953E9EB9AA6B2FAE6E30@phx.gbl>


I'm not sure of much right now, I have to rest and come back.

I'm quite dissatisifed with gcc/gnuld currently.
I don't want to tell the compiler anything really.
I want all function calls to always use x86 0xE8 opcode which is a direct pc-relative call, and then have the linker generate small stubs for anything that ends up external.
? That is how NT/x86 works and it is reasonably simple and efficient. Cross-.so calls would be slightly penalized, since if you did tell the compiler about them, it might inline the stub at the call. (The NT/x86 stubs are just one jmp instruction, but they aren't necessarily position-independent).
And I want to mostly give the linker a list of exports, plus maybe a few source annotations for exports.
I'd like source annotations and the lists to be additive. Maybe the "local: *" in my current code is wrong.


There seem to be so many features/switches, and it is hard/impossible to extract something simple, understandable, efficient.
I have trouble getting a mental model of how ld/ld.so work on most platforms.
The model on NT seems simple..

Attached is what I have so far..but I'm not entirely happy with it..
It is disabled in its current form.

It would also be nice if visibility(protected) worked.
It does sometimes, for calls, but not for taking the address of a function.

Anyway...
?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 10:50:42 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] limiting .so exports
>
> Can we not just push more information through to the back-ends for import_global/import_procedure? The front-end would need to know where it found the import (in the local package or in another imported package) but all that information would be derivable from m3linker wouldn't it?
>
>
>
>
> On 20 May 2010, at 09:59, Jay K wrote:
>
>>
>> limiting .so exports
>> (and direct binding to symbols in same .so)
>>
>>
>> FYI:
>>
>>
>> No clear question here, just a heads up regarding stuff that might be coming.
>>
>>
>>
>> I'm working on limiting .so exports to only "what they should be".
>>
>>
>> In particular, given:
>>
>> INTERFACE Foo;
>>
>> PROCEDURE Bar();
>>
>> END Foo.
>>
>> MODULE Foo;
>>
>> PROCEDURE F() = BEGIN ... END F;
>>
>> PROCEDURE Bar() = BEGIN F(); END Bar;
>>
>> END Foo.
>>
>>
>> Foo__F should not exported.
>> Foo__Bar should be.
>>
>>
>> Today they both would be.
>> Or at least in the recent past.
>> I already made a change in parse.c to reduce things.
>>
>>
>> However at that level I don't believe we have the needed information.
>> (needs investigation)
>>
>>
>> What I have is that in MxOut.m3, I write out all the symbols in
>> import_def_syms for modules.
>> Plus the _M3 and _I3 symbols.
>>
>>
>> That is most of the work.
>> However there are missing or non-ideal parts.
>>
>>
>> In the config files I then transform the list into the format
>> required by the compiler/linker. I was doing the transform in MxOut.m3
>> but it was getting to be "too much" work.
>>
>>
>> You also need to export anything marked <* EXTERNAL *> in interfaces.
>> I can get that list, however I have been using the "trick" of not
>> always implementing all EXTERNALs.
>> Sometimes the C implementation has #ifdefs around it.
>> So that becomes difficult.
>>
>>
>> gcc has __attribute__ and #pragma GCC visibility to control things
>> also, but this seems to conflict with giving a list in a file to
>> the compiler/linker.
>>
>>
>> What I have currently is that after compiling any C file, I run
>> nm on it to get its symbols.
>>
>>
>> I combine the nm output with the MxOut.m3 output.
>>
>>
>> Unfortunately that exports more of the C code than intended.
>> But code that always was exported -- like all of ThreadPThread.c.
>>
>>
>> As well something I haven't fixed yet is that lowercase interface
>> contents should not be exported, only capital Interface.
>>
>>
>> The list would be presented with
>> GNU ld: --version-script
>> Sun ld: -M for mapfile
>> Mac ld: --export-symbol-list
>>
>>
>> Sun ld and GNU ld accept roughly the same input.
>>
>>
>> I'm not sure how these two mechanisms compare.
>> It could be that it is better to use source/parse.c-level "visibility"
>> and not present the lists to the linker.
>> In particular that allows for not exporting more of the C.
>>
>>
>> I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.
>>
>>
>> The "list" approach should probably at least be used on NT/Cygwin.
>> Currently we export everything by mklib enumerating the symbols.
>>
>>
>> - Jay
>>
>
 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exports.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100520/f98ad3ee/attachment.txt>

From rodney_bates at lcwb.coop  Thu May 20 19:12:00 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 20 May 2010 12:12:00 -0500
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
Message-ID: <4BF56D60.2000403@lcwb.coop>

gcc even extends C with nested functions, and the support is there for that.  We use it too.

Beware:  The runtime model is, IMO, bizarre.  Definitely counterintuitive and unlike anything
you will ever see elsewhere.  There are two static links.  One is used for the first step
in following a static chain and points to the expected place in the target frame.  The other
is used of subsequent steps in chain-following, and points to somewhere inside the target
frame that is dependent on the target procedure.  It's the beginning of a subrecord where
all the nonlocally-referenced variables are collected.  The second static link is also
located in there.  All the nonlocally-referenced variables and parameters are duplicated
in there too.

I'm not sure I remembered these details exactly right.  Maybe both links point to the
subrecord, but one is located at a traditional procedure-independent, fixed location
in the frame, while the second is located in the subrecord.  Also, sometimes the first
static link value is kept in a register and never stored.

What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
scheme that, I believe came from interaction between nested procedures and inlining them.

But it's at the cost of what I would call an insanely complicated _runtime_ scheme.

It undermined m3gdb's handling of static links, and I don't think it's possible to fix
with the current design of emitting debug info very early.  The locations and target
offsets of these things aren't know until later, and m3gdb really needs to know them.


Jay K wrote:
> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
> Don't any of the other languages need it already?
> Ada? Pascal? Maybe the nested C function support?
> 
>  - Jay
> 


From jay.krell at cornell.edu  Fri May 21 03:43:08 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 01:43:08 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <4BF56D60.2000403@lcwb.coop>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>,
	, , <76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	<4BF56D60.2000403@lcwb.coop>
Message-ID: <COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>


Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
 
 
The static link is an extra parameter.
And, as such, also an extra local variable.
You only need one.
Each nesting level would follow another chain.
Or you can pass each nesting level as an extra parameter.
Or you can optimize and pass locals/parameters separately.
But there is an obvious straightforward non-optimized form. ?
 
 
Here, I worked it through:
 
 
 
Why doesn't it just look something like this:
 
 
nested:
 
void F1(int a, int b)
{
  int c = a + b;
 
  int f2()
  {
    int d = a + b;
 
    int f3()
    {
       return d + a + c;
    }
 
    return a + c + f3();
  }
 
  return f2();
}
 
not nested:
 

typedef struct {
  /* locals */
  int d;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
  f1_frame_t* f1;
} f2_frame_t;
 

typedef struct {
  /* locals */
  int c;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
  int a;
  int b;
} f1_frame_t;
 
 
int f3(f2_frame_t* f2)
{
    return f2->d + f2->f1->a + f2->f1->c;
}
 

int f2(f1_frame_t* f1)
{
  int d = f1->a + f1->b;
  return f1->a + f1->c + f3((f2_frame_t*)&d);
}
 

int F1(int a, int b)
{
  int c = a + b;
  return f2((f1_frame_t*)&c);
}

 
or, alernatively, almost the same, pass each chain as another parameter:
 

typedef struct {
  /* locals */
  int d;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
} f2_frame_t;
 

typedef struct {
  /* locals */
  int c;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
  int a;
  int b;
} f1_frame_t;
 
 
int f3(f2_frame_t* f2, f1_frame_t* f1)
{
    return f2->d + f1->a + f1->c;
}
 
 

int f2(f1_frame_t* f1)
{
  int d = f1->a + f1->b;
  return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
}
 

int F1(int a, int b)
{
  int c = a + b;
  return f2((f1_frame_t*)&c);
}
 
 
This should be easily adapted to any function call convention/sequence.
e.g. even if parameters are passed in registers.
 
 
And for that matter, why don't we just transform it to be like this?
  With the goal of reducing/eliminating gcc patches?
 
 
Am I missing something?
 

This form doesn't work?
 

Isn't reasonably simple?
 

Granted it might not be optimal. But it depends.
  You know, you can copy in the local/parameter values, but then you have
   to copy them out too. You can do analysis to show they aren't changed,
   in which case no need to copy them out.
  Similarly you can pass the parameters as separate parameters, by address
   if they are ever changed.

 
A portable transform couldn't depend on adjacency of locals and parameters.
It would have to either copy the parameters into the frame_t, or their addresses.
 
 
A portable form couldn't get the frame by taking the address of a "individual" local.
 
 
Here is portable form:
 
 
typedef struct {
  int d;
  f1_frame_t* f1;
} f2_frame_t;
 
typedef struct {
  int a;
  int b;
  int c;
} f1_frame_t;
 

int f3(f2_frame_t* f2)
{
    return f2->d + f2->f1->a + f2->f1->c;
}
 
int f2(f1_frame_t* f1)
{
  f2_frame_t f;
  f.f1 = f1;
  f.d = f1->a + f1->b;
  return f1->a + f1->c + f3(&f);
}
 
 
int F1(int a, int b)
{
  f1_frame_t f;
  f.a = a;
  f.b = b;
  f.c = a + b;
  return f2(&f);
}
 
 
or:
 
 
typedef struct {
  int d;
} f2_frame_t;
 
 
typedef struct {
  int a;
  int b;
  int c;
} f1_frame_t;
 
 
int f3(f2_frame_t* f2, f1_frame_t* f1)
{
    return f2->d + f1->a + f1->c;
}
 
 
int f2(f1_frame_t* f1)
{
  f2_frame_t f;
  f.d = f1->a + f1->b;
  return f1->a + f1->c + f3(&f, f1);
}

 
int F1(int a, int b)
{
  f1_frame_t f;
  f.a = a;
  f.b = b;
  f.c = a + b;
  return f2(&f);
}

 
 
 
 - Jay



----------------------------------------
> Date: Thu, 20 May 2010 12:12:00 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> gcc even extends C with nested functions, and the support is there for that. We use it too.
>
> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
> you will ever see elsewhere. There are two static links. One is used for the first step
> in following a static chain and points to the expected place in the target frame. The other
> is used of subsequent steps in chain-following, and points to somewhere inside the target
> frame that is dependent on the target procedure. It's the beginning of a subrecord where
> all the nonlocally-referenced variables are collected. The second static link is also
> located in there. All the nonlocally-referenced variables and parameters are duplicated
> in there too.
>
> I'm not sure I remembered these details exactly right. Maybe both links point to the
> subrecord, but one is located at a traditional procedure-independent, fixed location
> in the frame, while the second is located in the subrecord. Also, sometimes the first
> static link value is kept in a register and never stored.
>
> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
> scheme that, I believe came from interaction between nested procedures and inlining them.
>
> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>
> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
> with the current design of emitting debug info very early. The locations and target
> offsets of these things aren't know until later, and m3gdb really needs to know them.
>
>
> Jay K wrote:
>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>> Don't any of the other languages need it already?
>> Ada? Pascal? Maybe the nested C function support?
>>
>> - Jay
>> 		 	   		  

From hosking at cs.purdue.edu  Fri May 21 04:22:46 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 22:22:46 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	<4BF56D60.2000403@lcwb.coop>
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
Message-ID: <AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>

That is the standard formulation, but different architectures have different optimised forms (passing static link in a register, etc.).  In any case, gcc has its own weird way of doing things, which we mostly use, but from which we need a little extra support (hence the small amount of special tailoring).

On 20 May 2010, at 21:43, Jay K wrote:

> 
> Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
> 
> 
> The static link is an extra parameter.
> And, as such, also an extra local variable.
> You only need one.
> Each nesting level would follow another chain.
> Or you can pass each nesting level as an extra parameter.
> Or you can optimize and pass locals/parameters separately.
> But there is an obvious straightforward non-optimized form. ?
> 
> 
> Here, I worked it through:
> 
> 
> 
> Why doesn't it just look something like this:
> 
> 
> nested:
> 
> void F1(int a, int b)
> {
>  int c = a + b;
> 
>  int f2()
>  {
>    int d = a + b;
> 
>    int f3()
>    {
>       return d + a + c;
>    }
> 
>    return a + c + f3();
>  }
> 
>  return f2();
> }
> 
> not nested:
> 
> 
> typedef struct {
>  /* locals */
>  int d;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
>  f1_frame_t* f1;
> } f2_frame_t;
> 
> 
> typedef struct {
>  /* locals */
>  int c;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
>  int a;
>  int b;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2)
> {
>    return f2->d + f2->f1->a + f2->f1->c;
> }
> 
> 
> int f2(f1_frame_t* f1)
> {
>  int d = f1->a + f1->b;
>  return f1->a + f1->c + f3((f2_frame_t*)&d);
> }
> 
> 
> int F1(int a, int b)
> {
>  int c = a + b;
>  return f2((f1_frame_t*)&c);
> }
> 
> 
> or, alernatively, almost the same, pass each chain as another parameter:
> 
> 
> typedef struct {
>  /* locals */
>  int d;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
> } f2_frame_t;
> 
> 
> typedef struct {
>  /* locals */
>  int c;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
>  int a;
>  int b;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>    return f2->d + f1->a + f1->c;
> }
> 
> 
> 
> int f2(f1_frame_t* f1)
> {
>  int d = f1->a + f1->b;
>  return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
> }
> 
> 
> int F1(int a, int b)
> {
>  int c = a + b;
>  return f2((f1_frame_t*)&c);
> }
> 
> 
> This should be easily adapted to any function call convention/sequence.
> e.g. even if parameters are passed in registers.
> 
> 
> And for that matter, why don't we just transform it to be like this?
>  With the goal of reducing/eliminating gcc patches?
> 
> 
> Am I missing something?
> 
> 
> This form doesn't work?
> 
> 
> Isn't reasonably simple?
> 
> 
> Granted it might not be optimal. But it depends.
>  You know, you can copy in the local/parameter values, but then you have
>   to copy them out too. You can do analysis to show they aren't changed,
>   in which case no need to copy them out.
>  Similarly you can pass the parameters as separate parameters, by address
>   if they are ever changed.
> 
> 
> A portable transform couldn't depend on adjacency of locals and parameters.
> It would have to either copy the parameters into the frame_t, or their addresses.
> 
> 
> A portable form couldn't get the frame by taking the address of a "individual" local.
> 
> 
> Here is portable form:
> 
> 
> typedef struct {
>  int d;
>  f1_frame_t* f1;
> } f2_frame_t;
> 
> typedef struct {
>  int a;
>  int b;
>  int c;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2)
> {
>    return f2->d + f2->f1->a + f2->f1->c;
> }
> 
> int f2(f1_frame_t* f1)
> {
>  f2_frame_t f;
>  f.f1 = f1;
>  f.d = f1->a + f1->b;
>  return f1->a + f1->c + f3(&f);
> }
> 
> 
> int F1(int a, int b)
> {
>  f1_frame_t f;
>  f.a = a;
>  f.b = b;
>  f.c = a + b;
>  return f2(&f);
> }
> 
> 
> or:
> 
> 
> typedef struct {
>  int d;
> } f2_frame_t;
> 
> 
> typedef struct {
>  int a;
>  int b;
>  int c;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>    return f2->d + f1->a + f1->c;
> }
> 
> 
> int f2(f1_frame_t* f1)
> {
>  f2_frame_t f;
>  f.d = f1->a + f1->b;
>  return f1->a + f1->c + f3(&f, f1);
> }
> 
> 
> int F1(int a, int b)
> {
>  f1_frame_t f;
>  f.a = a;
>  f.b = b;
>  f.c = a + b;
>  return f2(&f);
> }
> 
> 
> 
> 
> - Jay
> 
> 
> 
> ----------------------------------------
>> Date: Thu, 20 May 2010 12:12:00 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> gcc even extends C with nested functions, and the support is there for that. We use it too.
>> 
>> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
>> you will ever see elsewhere. There are two static links. One is used for the first step
>> in following a static chain and points to the expected place in the target frame. The other
>> is used of subsequent steps in chain-following, and points to somewhere inside the target
>> frame that is dependent on the target procedure. It's the beginning of a subrecord where
>> all the nonlocally-referenced variables are collected. The second static link is also
>> located in there. All the nonlocally-referenced variables and parameters are duplicated
>> in there too.
>> 
>> I'm not sure I remembered these details exactly right. Maybe both links point to the
>> subrecord, but one is located at a traditional procedure-independent, fixed location
>> in the frame, while the second is located in the subrecord. Also, sometimes the first
>> static link value is kept in a register and never stored.
>> 
>> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
>> scheme that, I believe came from interaction between nested procedures and inlining them.
>> 
>> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>> 
>> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
>> with the current design of emitting debug info very early. The locations and target
>> offsets of these things aren't know until later, and m3gdb really needs to know them.
>> 
>> 
>> Jay K wrote:
>>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>>> Don't any of the other languages need it already?
>>> Ada? Pascal? Maybe the nested C function support?
>>> 
>>> - Jay
>>> 		 	   		  



From rcolebur at SCIRES.COM  Fri May 21 06:26:38 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 21 May 2010 00:26:38 -0400
Subject: [M3devel] m3core build failure
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>

I am getting a build error on Windows for m3core in HEAD branch:

"C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading

Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem.  Shouldn't this be "NT386" instead of "WIN32"?

Here is offending m3makefile:

C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
% Copyright (C) 1992, Digital Equipment Corporation
% All rights reserved.
% See the file COPYRIGHT for a full description.
%
% Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
%      modified on Wed Jun  9 17:25:51 PDT 1993 by harrison
%      modified on Thu May  6 12:11:46 PDT 1993 by muller
%      modified on Wed May  5 11:53:58 PDT 1993 by mjordan

include_dir ("Common")
include_dir (TARGET)
if equal(OS_TYPE, "WIN32")
  % long is 32bits even on 64bit Windows
  include("32BITS")
else
  include_dir (WORD_SIZE)
end

Regards,
Randy

________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100521/b1d89886/attachment.html>

From jay.krell at cornell.edu  Fri May 21 06:44:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 04:44:25 +0000
Subject: [M3devel] m3core build failure
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>


Oops, it should be include_dir.
 
 
32BITS is deliberate -- 32bits has a 32bit long, 64bits has a 64bit long, all Win32 platforms, 32bit or 64bit, have a 32bit long.
 
 
We really should just not have long anywhere, but that might be difficult to achieve.
   The often purported portable meaning of "long", that is a pointer-sized, is false.
The pointer sized integers are INTEGER and Word.T, not "long".
 
 
 
 - Jay

________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Fri, 21 May 2010 00:26:38 -0400
> Subject: [M3devel] m3core build failure
>
>
>
>
>
>
>
>
>
>
>
>
> I am getting a build error on Windows for m3core in HEAD branch:
>
>
>
>
>
> "C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
>
>
> unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading
>
>
>
>
>
> Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem. Shouldn?t this be ?NT386? instead of ?WIN32??
>
>
>
>
>
> Here is offending m3makefile:
>
>
>
>
>
> C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
>
>
> % Copyright (C) 1992, Digital Equipment Corporation
>
>
> % All rights reserved.
>
>
> % See the file COPYRIGHT for a full description.
>
>
> %
>
>
> % Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
>
>
> % modified on Wed Jun 9 17:25:51 PDT 1993 by harrison
>
>
> % modified on Thu May 6 12:11:46 PDT 1993 by muller
>
>
> % modified on Wed May 5 11:53:58 PDT 1993 by mjordan
>
>
>
>
>
> include_dir ("Common")
>
>
> include_dir (TARGET)
>
>
> if equal(OS_TYPE, "WIN32")
>
>
> % long is 32bits even on 64bit Windows
>
>
> include("32BITS")
>
>
> else
>
>
> include_dir (WORD_SIZE)
>
>
> end
>
>
>
>
>
> Regards,
>
>
> Randy
>
>
>
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation.
> If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately
> and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>
>
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical
> data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data
> may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will
> comply with all applicable ITAR, EAR and embargo compliance requirements.
> 		 	   		  

From jay.krell at cornell.edu  Fri May 21 06:47:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 04:47:54 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	,,<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	,,<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	, , <2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, ,
	<4BF56D60.2000403@lcwb.coop>,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>
Message-ID: <COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>


Maybe we can/should transform into one of the forms I show and dispense with any gcc support?
At the cost of losing some "easy" optimization..of nested functions?
  "easy" as in, occurs even without -O2, but might occur with -O2?
 
 
I know what you mean -- NT386 passes the static link in ecx.
This is "ok" because in C++ the "this" pointer is passed in ecx.
 
 
Passing it as "just" another parameter might be less efficient, but ok?
  And really, it'd only be less efficient on one architecture -- 32bit x86.
  And maybe not all x86s -- depending on if some ABIs have a register based calling convention.
 
 
We don't need any actual ABI-compatibility with anything here, do we?
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 22:22:46 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> That is the standard formulation, but different architectures have different optimised forms (passing static link in a register, etc.). In any case, gcc has its own weird way of doing things, which we mostly use, but from which we need a little extra support (hence the small amount of special tailoring).
>
> On 20 May 2010, at 21:43, Jay K wrote:
>
>>
>> Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
>>
>>
>> The static link is an extra parameter.
>> And, as such, also an extra local variable.
>> You only need one.
>> Each nesting level would follow another chain.
>> Or you can pass each nesting level as an extra parameter.
>> Or you can optimize and pass locals/parameters separately.
>> But there is an obvious straightforward non-optimized form. ?
>>
>>
>> Here, I worked it through:
>>
>>
>>
>> Why doesn't it just look something like this:
>>
>>
>> nested:
>>
>> void F1(int a, int b)
>> {
>> int c = a + b;
>>
>> int f2()
>> {
>> int d = a + b;
>>
>> int f3()
>> {
>> return d + a + c;
>> }
>>
>> return a + c + f3();
>> }
>>
>> return f2();
>> }
>>
>> not nested:
>>
>>
>> typedef struct {
>> /* locals */
>> int d;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> f1_frame_t* f1;
>> } f2_frame_t;
>>
>>
>> typedef struct {
>> /* locals */
>> int c;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> int a;
>> int b;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2)
>> {
>> return f2->d + f2->f1->a + f2->f1->c;
>> }
>>
>>
>> int f2(f1_frame_t* f1)
>> {
>> int d = f1->a + f1->b;
>> return f1->a + f1->c + f3((f2_frame_t*)&d);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> int c = a + b;
>> return f2((f1_frame_t*)&c);
>> }
>>
>>
>> or, alernatively, almost the same, pass each chain as another parameter:
>>
>>
>> typedef struct {
>> /* locals */
>> int d;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> } f2_frame_t;
>>
>>
>> typedef struct {
>> /* locals */
>> int c;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> int a;
>> int b;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2, f1_frame_t* f1)
>> {
>> return f2->d + f1->a + f1->c;
>> }
>>
>>
>>
>> int f2(f1_frame_t* f1)
>> {
>> int d = f1->a + f1->b;
>> return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> int c = a + b;
>> return f2((f1_frame_t*)&c);
>> }
>>
>>
>> This should be easily adapted to any function call convention/sequence.
>> e.g. even if parameters are passed in registers.
>>
>>
>> And for that matter, why don't we just transform it to be like this?
>> With the goal of reducing/eliminating gcc patches?
>>
>>
>> Am I missing something?
>>
>>
>> This form doesn't work?
>>
>>
>> Isn't reasonably simple?
>>
>>
>> Granted it might not be optimal. But it depends.
>> You know, you can copy in the local/parameter values, but then you have
>> to copy them out too. You can do analysis to show they aren't changed,
>> in which case no need to copy them out.
>> Similarly you can pass the parameters as separate parameters, by address
>> if they are ever changed.
>>
>>
>> A portable transform couldn't depend on adjacency of locals and parameters.
>> It would have to either copy the parameters into the frame_t, or their addresses.
>>
>>
>> A portable form couldn't get the frame by taking the address of a "individual" local.
>>
>>
>> Here is portable form:
>>
>>
>> typedef struct {
>> int d;
>> f1_frame_t* f1;
>> } f2_frame_t;
>>
>> typedef struct {
>> int a;
>> int b;
>> int c;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2)
>> {
>> return f2->d + f2->f1->a + f2->f1->c;
>> }
>>
>> int f2(f1_frame_t* f1)
>> {
>> f2_frame_t f;
>> f.f1 = f1;
>> f.d = f1->a + f1->b;
>> return f1->a + f1->c + f3(&f);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> f1_frame_t f;
>> f.a = a;
>> f.b = b;
>> f.c = a + b;
>> return f2(&f);
>> }
>>
>>
>> or:
>>
>>
>> typedef struct {
>> int d;
>> } f2_frame_t;
>>
>>
>> typedef struct {
>> int a;
>> int b;
>> int c;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2, f1_frame_t* f1)
>> {
>> return f2->d + f1->a + f1->c;
>> }
>>
>>
>> int f2(f1_frame_t* f1)
>> {
>> f2_frame_t f;
>> f.d = f1->a + f1->b;
>> return f1->a + f1->c + f3(&f, f1);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> f1_frame_t f;
>> f.a = a;
>> f.b = b;
>> f.c = a + b;
>> return f2(&f);
>> }
>>
>>
>>
>>
>> - Jay
>>
>>
>>
>> ----------------------------------------
>>> Date: Thu, 20 May 2010 12:12:00 -0500
>>> From: rodney_bates at lcwb.coop
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>> gcc even extends C with nested functions, and the support is there for that. We use it too.
>>>
>>> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
>>> you will ever see elsewhere. There are two static links. One is used for the first step
>>> in following a static chain and points to the expected place in the target frame. The other
>>> is used of subsequent steps in chain-following, and points to somewhere inside the target
>>> frame that is dependent on the target procedure. It's the beginning of a subrecord where
>>> all the nonlocally-referenced variables are collected. The second static link is also
>>> located in there. All the nonlocally-referenced variables and parameters are duplicated
>>> in there too.
>>>
>>> I'm not sure I remembered these details exactly right. Maybe both links point to the
>>> subrecord, but one is located at a traditional procedure-independent, fixed location
>>> in the frame, while the second is located in the subrecord. Also, sometimes the first
>>> static link value is kept in a register and never stored.
>>>
>>> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
>>> scheme that, I believe came from interaction between nested procedures and inlining them.
>>>
>>> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>>>
>>> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
>>> with the current design of emitting debug info very early. The locations and target
>>> offsets of these things aren't know until later, and m3gdb really needs to know them.
>>>
>>>
>>> Jay K wrote:
>>>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>>>> Don't any of the other languages need it already?
>>>> Ada? Pascal? Maybe the nested C function support?
>>>>
>>>> - Jay
>>>>
> 		 	   		  

From rcolebur at SCIRES.COM  Fri May 21 07:00:17 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 21 May 2010 01:00:17 -0400
Subject: [M3devel] m3core build failure
In-Reply-To: <COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>
References: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C191D33D@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Thanks for the reply.

I don't think that is all that is wrong.  I changed to "include_dir", but now I am getting other errors.  For example:

new source -> compiling UnixC.c
cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
Oi -c ..\\src\\unix\\Common\\UnixC.c
UnixC.c
..\\src\\unix\\Common\\UnixC.c(95) : error C2375: 'Unix__open' : redefinition; d
ifferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(329) : see declaration of 'Un
ix__open'
..\\src\\unix\\Common\\UnixC.c(96) : error C2375: 'Unix__umask' : redefinition;
different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(337) : see declaration of 'Un
ix__umask'
..\\src\\unix\\Common\\UnixC.c(97) : error C2375: 'Unix__chmod' : redefinition;
different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(357) : see declaration of 'Un
ix__chmod'
..\\src\\unix\\Common\\UnixC.c(98) : error C2375: 'Unix__creat' : redefinition;
different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(361) : see declaration of 'Un
ix__creat'
..\\src\\unix\\Common\\UnixC.c(99) : error C2375: 'Unix__dup' : redefinition; di
fferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(362) : see declaration of 'Un
ix__dup'
  compile_c => 2
C compiler failed compiling: ..\src\unix\Common\UnixC.c
new source -> compiling Uin.c
cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
Oi -c ..\\src\\unix\\Common\\Uin.c
Uin.c
..\\src\\unix\\Common\\Uin.c(14) : error C2375: 'Uin__ntohl' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(364) : see declaration of 'Ui
n__ntohl'
..\\src\\unix\\Common\\Uin.c(15) : error C2375: 'Uin__ntohs' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(365) : see declaration of 'Ui
n__ntohs'
..\\src\\unix\\Common\\Uin.c(16) : error C2375: 'Uin__htonl' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(366) : see declaration of 'Ui
n__htonl'
..\\src\\unix\\Common\\Uin.c(17) : error C2375: 'Uin__htons' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(367) : see declaration of 'Ui
n__htons'
  compile_c => 2
C compiler failed compiling: ..\src\unix\Common\Uin.c
new source -> compiling Usocket.c
cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
Oi -c ..\\src\\unix\\Common\\Usocket.c
Usocket.c
..\\src\\unix\\Common\\Usocket.c(65) : error C2375: 'Usocket__listen' : redefini
tion; different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(283) : see declaration of 'Us
ocket__listen'
..\\src\\unix\\Common\\Usocket.c(66) : error C2375: 'Usocket__shutdown' : redefi
nition; different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(284) : see declaration of 'Us
ocket__shutdown'
..\\src\\unix\\Common\\Usocket.c(67) : error C2375: 'Usocket__socket' : redefini
tion; different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(285) : see declaration of 'Us
ocket__socket'
  compile_c => 2
C compiler failed compiling: ..\src\unix\Common\Usocket.c
compilation failed => not building library "m3core.lib"
Fatal Error: package build failed

Regards,
Randy

-----Original Message-----
From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, May 21, 2010 12:44 AM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] m3core build failure


Oops, it should be include_dir.


32BITS is deliberate -- 32bits has a 32bit long, 64bits has a 64bit long, all Win32 platforms, 32bit or 64bit, have a 32bit long.


We really should just not have long anywhere, but that might be difficult to achieve.
   The often purported portable meaning of "long", that is a pointer-sized, is false.
The pointer sized integers are INTEGER and Word.T, not "long".



 - Jay

________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Fri, 21 May 2010 00:26:38 -0400
> Subject: [M3devel] m3core build failure
>
>
>
>
>
>
>
>
>
>
>
>
> I am getting a build error on Windows for m3core in HEAD branch:
>
>
>
>
>
> "C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
>
>
> unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading
>
>
>
>
>
> Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem. Shouldn't this be "NT386" instead of "WIN32"?
>
>
>
>
>
> Here is offending m3makefile:
>
>
>
>
>
> C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
>
>
> % Copyright (C) 1992, Digital Equipment Corporation
>
>
> % All rights reserved.
>
>
> % See the file COPYRIGHT for a full description.
>
>
> %
>
>
> % Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
>
>
> % modified on Wed Jun 9 17:25:51 PDT 1993 by harrison
>
>
> % modified on Thu May 6 12:11:46 PDT 1993 by muller
>
>
> % modified on Wed May 5 11:53:58 PDT 1993 by mjordan
>
>
>
>
>
> include_dir ("Common")
>
>
> include_dir (TARGET)
>
>
> if equal(OS_TYPE, "WIN32")
>
>
> % long is 32bits even on 64bit Windows
>
>
> include("32BITS")
>
>
> else
>
>
> include_dir (WORD_SIZE)
>
>
> end
>
>
>
>
>
> Regards,
>
>
> Randy
>
>
>
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation.
> If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately
> and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>
>
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical
> data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data
> may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will
> comply with all applicable ITAR, EAR and embargo compliance requirements.
>

CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s).  This email may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.


From jay.krell at cornell.edu  Fri May 21 07:11:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 05:11:07 +0000
Subject: [M3devel] m3core build failure
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8711C191D33D@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>,
	<COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8711C191D33D@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W31CE7568078110BBF4309AE6E40@phx.gbl>


I'll fix it later. Anything unix/common that doesn't compile for Win32, you can if out, even the whole directory. They aren't used currently.
 
 
 - Jay

----------------------------------------
> From: rcolebur at SCIRES.COM
> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> Date: Fri, 21 May 2010 01:00:17 -0400
> Subject: Re: [M3devel] m3core build failure
>
> Jay:
>
> Thanks for the reply.
>
> I don't think that is all that is wrong. I changed to "include_dir", but now I am getting other errors. For example:
>
> new source -> compiling UnixC.c
> cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
> n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
> on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
> src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
> Oi -c ..\\src\\unix\\Common\\UnixC.c
> UnixC.c
> ..\\src\\unix\\Common\\UnixC.c(95) : error C2375: 'Unix__open' : redefinition; d
> ifferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(329) : see declaration of 'Un
> ix__open'
> ..\\src\\unix\\Common\\UnixC.c(96) : error C2375: 'Unix__umask' : redefinition;
> different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(337) : see declaration of 'Un
> ix__umask'
> ..\\src\\unix\\Common\\UnixC.c(97) : error C2375: 'Unix__chmod' : redefinition;
> different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(357) : see declaration of 'Un
> ix__chmod'
> ..\\src\\unix\\Common\\UnixC.c(98) : error C2375: 'Unix__creat' : redefinition;
> different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(361) : see declaration of 'Un
> ix__creat'
> ..\\src\\unix\\Common\\UnixC.c(99) : error C2375: 'Unix__dup' : redefinition; di
> fferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(362) : see declaration of 'Un
> ix__dup'
> compile_c => 2
> C compiler failed compiling: ..\src\unix\Common\UnixC.c
> new source -> compiling Uin.c
> cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
> n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
> on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
> src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
> Oi -c ..\\src\\unix\\Common\\Uin.c
> Uin.c
> ..\\src\\unix\\Common\\Uin.c(14) : error C2375: 'Uin__ntohl' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(364) : see declaration of 'Ui
> n__ntohl'
> ..\\src\\unix\\Common\\Uin.c(15) : error C2375: 'Uin__ntohs' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(365) : see declaration of 'Ui
> n__ntohs'
> ..\\src\\unix\\Common\\Uin.c(16) : error C2375: 'Uin__htonl' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(366) : see declaration of 'Ui
> n__htonl'
> ..\\src\\unix\\Common\\Uin.c(17) : error C2375: 'Uin__htons' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(367) : see declaration of 'Ui
> n__htons'
> compile_c => 2
> C compiler failed compiling: ..\src\unix\Common\Uin.c
> new source -> compiling Usocket.c
> cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
> n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
> on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
> src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
> Oi -c ..\\src\\unix\\Common\\Usocket.c
> Usocket.c
> ..\\src\\unix\\Common\\Usocket.c(65) : error C2375: 'Usocket__listen' : redefini
> tion; different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(283) : see declaration of 'Us
> ocket__listen'
> ..\\src\\unix\\Common\\Usocket.c(66) : error C2375: 'Usocket__shutdown' : redefi
> nition; different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(284) : see declaration of 'Us
> ocket__shutdown'
> ..\\src\\unix\\Common\\Usocket.c(67) : error C2375: 'Usocket__socket' : redefini
> tion; different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(285) : see declaration of 'Us
> ocket__socket'
> compile_c => 2
> C compiler failed compiling: ..\src\unix\Common\Usocket.c
> compilation failed => not building library "m3core.lib"
> Fatal Error: package build failed
>
> Regards,
> Randy
>
> -----Original Message-----
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Friday, May 21, 2010 12:44 AM
> To: Coleburn, Randy; m3devel
> Subject: RE: [M3devel] m3core build failure
>
>
> Oops, it should be include_dir.
>
>
> 32BITS is deliberate -- 32bits has a 32bit long, 64bits has a 64bit long, all Win32 platforms, 32bit or 64bit, have a 32bit long.
>
>
> We really should just not have long anywhere, but that might be difficult to achieve.
> The often purported portable meaning of "long", that is a pointer-sized, is false.
> The pointer sized integers are INTEGER and Word.T, not "long".
>
>
>
> - Jay
>
> ________________________________
>> From: rcolebur at SCIRES.COM
>> To: m3devel at elegosoft.com
>> Date: Fri, 21 May 2010 00:26:38 -0400
>> Subject: [M3devel] m3core build failure
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I am getting a build error on Windows for m3core in HEAD branch:
>>
>>
>>
>>
>>
>> "C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
>>
>>
>> unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading
>>
>>
>>
>>
>>
>> Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem. Shouldn't this be "NT386" instead of "WIN32"?
>>
>>
>>
>>
>>
>> Here is offending m3makefile:
>>
>>
>>
>>
>>
>> C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
>>
>>
>> % Copyright (C) 1992, Digital Equipment Corporation
>>
>>
>> % All rights reserved.
>>
>>
>> % See the file COPYRIGHT for a full description.
>>
>>
>> %
>>
>>
>> % Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
>>
>>
>> % modified on Wed Jun 9 17:25:51 PDT 1993 by harrison
>>
>>
>> % modified on Thu May 6 12:11:46 PDT 1993 by muller
>>
>>
>> % modified on Wed May 5 11:53:58 PDT 1993 by mjordan
>>
>>
>>
>>
>>
>> include_dir ("Common")
>>
>>
>> include_dir (TARGET)
>>
>>
>> if equal(OS_TYPE, "WIN32")
>>
>>
>> % long is 32bits even on 64bit Windows
>>
>>
>> include("32BITS")
>>
>>
>> else
>>
>>
>> include_dir (WORD_SIZE)
>>
>>
>> end
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>> Randy
>>
>>
>>
>>
>> ________________________________
>>
>> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation.
>> If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately
>> and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>>
>>
>>
>> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical
>> data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data
>> may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will
>> comply with all applicable ITAR, EAR and embargo compliance requirements.
>>
>
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. 		 	   		  

From mika at async.async.caltech.edu  Fri May 21 07:37:56 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 20 May 2010 22:37:56 -0700
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl> 
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, ,
	<4BF56D60.2000403@lcwb.coop>,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>
Message-ID: <20100521053756.D74951A2094@async.async.caltech.edu>


As I recall it the "Dragon Book" has a whole section on this topic of
nested functions in Pascal.  Including Dijkstra's "display".  I'm not
an expert, just remember reading it.  Wirth also talks about it in his
"Good Ideas, Through the Looking Glass" (where he says the display
might be a pessimization).

     Mika

Jay K writes:
>
>Maybe we can/should transform into one of the forms I show and dispense wit=
>h any gcc support?
>At the cost of losing some "easy" optimization..of nested functions?
>  "easy" as in=2C occurs even without -O2=2C but might occur with -O2?
>=20
>=20
>I know what you mean -- NT386 passes the static link in ecx.
>This is "ok" because in C++ the "this" pointer is passed in ecx.
>=20
>=20
>Passing it as "just" another parameter might be less efficient=2C but ok?
>  And really=2C it'd only be less efficient on one architecture -- 32bit x8=
>6.
>  And maybe not all x86s -- depending on if some ABIs have a register based=
> calling convention.
>=20
>=20
>We don't need any actual ABI-compatibility with anything here=2C do we?
>=20
>=20
> - Jay
>
>
>----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu=2C 20 May 2010 22:22:46 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>> That is the standard formulation=2C but different architectures have diff=
>erent optimised forms (passing static link in a register=2C etc.). In any c=
>ase=2C gcc has its own weird way of doing things=2C which we mostly use=2C =
>but from which we need a little extra support (hence the small amount of sp=
>ecial tailoring).
>>
>> On 20 May 2010=2C at 21:43=2C Jay K wrote:
>>
>>>
>>> Wierd. To me the model to follow is almost obvious. It should be obvious=
> to everyone and implemented the way I have in mind. :)
>>>
>>>
>>> The static link is an extra parameter.
>>> And=2C as such=2C also an extra local variable.
>>> You only need one.
>>> Each nesting level would follow another chain.
>>> Or you can pass each nesting level as an extra parameter.
>>> Or you can optimize and pass locals/parameters separately.
>>> But there is an obvious straightforward non-optimized form. ?
>>>
>>>
>>> Here=2C I worked it through:
>>>
>>>
>>>
>>> Why doesn't it just look something like this:
>>>
>>>
>>> nested:
>>>
>>> void F1(int a=2C int b)
>>> {
>>> int c =3D a + b=3B
>>>
>>> int f2()
>>> {
>>> int d =3D a + b=3B
>>>
>>> int f3()
>>> {
>>> return d + a + c=3B
>>> }
>>>
>>> return a + c + f3()=3B
>>> }
>>>
>>> return f2()=3B
>>> }
>>>
>>> not nested:
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int d=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> f1_frame_t* f1=3B
>>> } f2_frame_t=3B
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int c=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> int a=3B
>>> int b=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2)
>>> {
>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>> }
>>>
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> int d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> int c =3D a + b=3B
>>> return f2((f1_frame_t*)&c)=3B
>>> }
>>>
>>>
>>> or=2C alernatively=2C almost the same=2C pass each chain as another para=
>meter:
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int d=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> } f2_frame_t=3B
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int c=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> int a=3B
>>> int b=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>> {
>>> return f2->d + f1->a + f1->c=3B
>>> }
>>>
>>>
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> int d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3((f2_frame_t*)&d=2C f1)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> int c =3D a + b=3B
>>> return f2((f1_frame_t*)&c)=3B
>>> }
>>>
>>>
>>> This should be easily adapted to any function call convention/sequence.
>>> e.g. even if parameters are passed in registers.
>>>
>>>
>>> And for that matter=2C why don't we just transform it to be like this?
>>> With the goal of reducing/eliminating gcc patches?
>>>
>>>
>>> Am I missing something?
>>>
>>>
>>> This form doesn't work?
>>>
>>>
>>> Isn't reasonably simple?
>>>
>>>
>>> Granted it might not be optimal. But it depends.
>>> You know=2C you can copy in the local/parameter values=2C but then you h=
>ave
>>> to copy them out too. You can do analysis to show they aren't changed=2C
>>> in which case no need to copy them out.
>>> Similarly you can pass the parameters as separate parameters=2C by addre=
>ss
>>> if they are ever changed.
>>>
>>>
>>> A portable transform couldn't depend on adjacency of locals and paramete=
>rs.
>>> It would have to either copy the parameters into the frame_t=2C or their=
> addresses.
>>>
>>>
>>> A portable form couldn't get the frame by taking the address of a "indiv=
>idual" local.
>>>
>>>
>>> Here is portable form:
>>>
>>>
>>> typedef struct {
>>> int d=3B
>>> f1_frame_t* f1=3B
>>> } f2_frame_t=3B
>>>
>>> typedef struct {
>>> int a=3B
>>> int b=3B
>>> int c=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2)
>>> {
>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>> }
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> f2_frame_t f=3B
>>> f.f1 =3D f1=3B
>>> f.d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3(&f)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> f1_frame_t f=3B
>>> f.a =3D a=3B
>>> f.b =3D b=3B
>>> f.c =3D a + b=3B
>>> return f2(&f)=3B
>>> }
>>>
>>>
>>> or:
>>>
>>>
>>> typedef struct {
>>> int d=3B
>>> } f2_frame_t=3B
>>>
>>>
>>> typedef struct {
>>> int a=3B
>>> int b=3B
>>> int c=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>> {
>>> return f2->d + f1->a + f1->c=3B
>>> }
>>>
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> f2_frame_t f=3B
>>> f.d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3(&f=2C f1)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> f1_frame_t f=3B
>>> f.a =3D a=3B
>>> f.b =3D b=3B
>>> f.c =3D a + b=3B
>>> return f2(&f)=3B
>>> }
>>>
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Date: Thu=2C 20 May 2010 12:12:00 -0500
>>>> From: rodney_bates at lcwb.coop
>>>> To: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>
>>>> gcc even extends C with nested functions=2C and the support is there fo=
>r that. We use it too.
>>>>
>>>> Beware: The runtime model is=2C IMO=2C bizarre. Definitely counterintui=
>tive and unlike anything
>>>> you will ever see elsewhere. There are two static links. One is used fo=
>r the first step
>>>> in following a static chain and points to the expected place in the tar=
>get frame. The other
>>>> is used of subsequent steps in chain-following=2C and points to somewhe=
>re inside the target
>>>> frame that is dependent on the target procedure. It's the beginning of =
>a subrecord where
>>>> all the nonlocally-referenced variables are collected. The second stati=
>c link is also
>>>> located in there. All the nonlocally-referenced variables and parameter=
>s are duplicated
>>>> in there too.
>>>>
>>>> I'm not sure I remembered these details exactly right. Maybe both links=
> point to the
>>>> subrecord=2C but one is located at a traditional procedure-independent=
>=2C fixed location
>>>> in the frame=2C while the second is located in the subrecord. Also=2C s=
>ometimes the first
>>>> static link value is kept in a register and never stored.
>>>>
>>>> What this all apparently accomplishes is simplifying an "insanely compl=
>icated" _compile-time_
>>>> scheme that=2C I believe came from interaction between nested procedure=
>s and inlining them.
>>>>
>>>> But it's at the cost of what I would call an insanely complicated _runt=
>ime_ scheme.
>>>>
>>>> It undermined m3gdb's handling of static links=2C and I don't think it'=
>s possible to fix
>>>> with the current design of emitting debug info very early. The location=
>s and target
>>>> offsets of these things aren't know until later=2C and m3gdb really nee=
>ds to know them.
>>>>
>>>>
>>>> Jay K wrote:
>>>>> What I meant regarding "static chain" was more like "does gcc already =
>have support that we can use".
>>>>> Don't any of the other languages need it already?
>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>
>>>>> - Jay
>>>>>
>> 		 	   		  =


From jay.krell at cornell.edu  Fri May 21 08:41:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 06:41:42 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <20100521053756.D74951A2094@async.async.caltech.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , ,
	,,<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	,,<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	,,<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	,,<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	, , <4BF56D60.2000403@lcwb.coop>, ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>,
	<20100521053756.D74951A2094@async.async.caltech.edu>
Message-ID: <COL101-W62B5841AA922ECC333168E6E40@phx.gbl>


Thanks for the reference!
 
search for "Good Ideas, Through the Looking Glass"
finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_origFig.pdf"
(I don't need to provide the link really.)
 
 - Jay

----------------------------------------
> To: jay.krell at cornell.edu
> Date: Thu, 20 May 2010 22:37:56 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
>
> As I recall it the "Dragon Book" has a whole section on this topic of
> nested functions in Pascal. Including Dijkstra's "display". I'm not
> an expert, just remember reading it. Wirth also talks about it in his
> "Good Ideas, Through the Looking Glass" (where he says the display
> might be a pessimization).
>
> Mika
>
> Jay K writes:
>>
>>Maybe we can/should transform into one of the forms I show and dispense wit=
>>h any gcc support?
>>At the cost of losing some "easy" optimization..of nested functions?
>> "easy" as in=2C occurs even without -O2=2C but might occur with -O2?
>>=20
>>=20
>>I know what you mean -- NT386 passes the static link in ecx.
>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>=20
>>=20
>>Passing it as "just" another parameter might be less efficient=2C but ok?
>> And really=2C it'd only be less efficient on one architecture -- 32bit x8=
>>6.
>> And maybe not all x86s -- depending on if some ABIs have a register based=
>> calling convention.
>>=20
>>=20
>>We don't need any actual ABI-compatibility with anything here=2C do we?
>>=20
>>=20
>> - Jay
>>
>>
>>----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Thu=2C 20 May 2010 22:22:46 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>> That is the standard formulation=2C but different architectures have diff=
>>erent optimised forms (passing static link in a register=2C etc.). In any c=
>>ase=2C gcc has its own weird way of doing things=2C which we mostly use=2C =
>>but from which we need a little extra support (hence the small amount of sp=
>>ecial tailoring).
>>>
>>> On 20 May 2010=2C at 21:43=2C Jay K wrote:
>>>
>>>>
>>>> Wierd. To me the model to follow is almost obvious. It should be obvious=
>> to everyone and implemented the way I have in mind. :)
>>>>
>>>>
>>>> The static link is an extra parameter.
>>>> And=2C as such=2C also an extra local variable.
>>>> You only need one.
>>>> Each nesting level would follow another chain.
>>>> Or you can pass each nesting level as an extra parameter.
>>>> Or you can optimize and pass locals/parameters separately.
>>>> But there is an obvious straightforward non-optimized form. ?
>>>>
>>>>
>>>> Here=2C I worked it through:
>>>>
>>>>
>>>>
>>>> Why doesn't it just look something like this:
>>>>
>>>>
>>>> nested:
>>>>
>>>> void F1(int a=2C int b)
>>>> {
>>>> int c =3D a + b=3B
>>>>
>>>> int f2()
>>>> {
>>>> int d =3D a + b=3B
>>>>
>>>> int f3()
>>>> {
>>>> return d + a + c=3B
>>>> }
>>>>
>>>> return a + c + f3()=3B
>>>> }
>>>>
>>>> return f2()=3B
>>>> }
>>>>
>>>> not nested:
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int d=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> f1_frame_t* f1=3B
>>>> } f2_frame_t=3B
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int c=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> int a=3B
>>>> int b=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2)
>>>> {
>>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>>> }
>>>>
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> int d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> int c =3D a + b=3B
>>>> return f2((f1_frame_t*)&c)=3B
>>>> }
>>>>
>>>>
>>>> or=2C alernatively=2C almost the same=2C pass each chain as another para=
>>meter:
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int d=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> } f2_frame_t=3B
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int c=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> int a=3B
>>>> int b=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>>> {
>>>> return f2->d + f1->a + f1->c=3B
>>>> }
>>>>
>>>>
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> int d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=2C f1)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> int c =3D a + b=3B
>>>> return f2((f1_frame_t*)&c)=3B
>>>> }
>>>>
>>>>
>>>> This should be easily adapted to any function call convention/sequence.
>>>> e.g. even if parameters are passed in registers.
>>>>
>>>>
>>>> And for that matter=2C why don't we just transform it to be like this?
>>>> With the goal of reducing/eliminating gcc patches?
>>>>
>>>>
>>>> Am I missing something?
>>>>
>>>>
>>>> This form doesn't work?
>>>>
>>>>
>>>> Isn't reasonably simple?
>>>>
>>>>
>>>> Granted it might not be optimal. But it depends.
>>>> You know=2C you can copy in the local/parameter values=2C but then you h=
>>ave
>>>> to copy them out too. You can do analysis to show they aren't changed=2C
>>>> in which case no need to copy them out.
>>>> Similarly you can pass the parameters as separate parameters=2C by addre=
>>ss
>>>> if they are ever changed.
>>>>
>>>>
>>>> A portable transform couldn't depend on adjacency of locals and paramete=
>>rs.
>>>> It would have to either copy the parameters into the frame_t=2C or their=
>> addresses.
>>>>
>>>>
>>>> A portable form couldn't get the frame by taking the address of a "indiv=
>>idual" local.
>>>>
>>>>
>>>> Here is portable form:
>>>>
>>>>
>>>> typedef struct {
>>>> int d=3B
>>>> f1_frame_t* f1=3B
>>>> } f2_frame_t=3B
>>>>
>>>> typedef struct {
>>>> int a=3B
>>>> int b=3B
>>>> int c=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2)
>>>> {
>>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>>> }
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> f2_frame_t f=3B
>>>> f.f1 =3D f1=3B
>>>> f.d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3(&f)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> f1_frame_t f=3B
>>>> f.a =3D a=3B
>>>> f.b =3D b=3B
>>>> f.c =3D a + b=3B
>>>> return f2(&f)=3B
>>>> }
>>>>
>>>>
>>>> or:
>>>>
>>>>
>>>> typedef struct {
>>>> int d=3B
>>>> } f2_frame_t=3B
>>>>
>>>>
>>>> typedef struct {
>>>> int a=3B
>>>> int b=3B
>>>> int c=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>>> {
>>>> return f2->d + f1->a + f1->c=3B
>>>> }
>>>>
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> f2_frame_t f=3B
>>>> f.d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3(&f=2C f1)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> f1_frame_t f=3B
>>>> f.a =3D a=3B
>>>> f.b =3D b=3B
>>>> f.c =3D a + b=3B
>>>> return f2(&f)=3B
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Thu=2C 20 May 2010 12:12:00 -0500
>>>>> From: rodney_bates at lcwb.coop
>>>>> To: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>
>>>>> gcc even extends C with nested functions=2C and the support is there fo=
>>r that. We use it too.
>>>>>
>>>>> Beware: The runtime model is=2C IMO=2C bizarre. Definitely counterintui=
>>tive and unlike anything
>>>>> you will ever see elsewhere. There are two static links. One is used fo=
>>r the first step
>>>>> in following a static chain and points to the expected place in the tar=
>>get frame. The other
>>>>> is used of subsequent steps in chain-following=2C and points to somewhe=
>>re inside the target
>>>>> frame that is dependent on the target procedure. It's the beginning of =
>>a subrecord where
>>>>> all the nonlocally-referenced variables are collected. The second stati=
>>c link is also
>>>>> located in there. All the nonlocally-referenced variables and parameter=
>>s are duplicated
>>>>> in there too.
>>>>>
>>>>> I'm not sure I remembered these details exactly right. Maybe both links=
>> point to the
>>>>> subrecord=2C but one is located at a traditional procedure-independent=
>>=2C fixed location
>>>>> in the frame=2C while the second is located in the subrecord. Also=2C s=
>>ometimes the first
>>>>> static link value is kept in a register and never stored.
>>>>>
>>>>> What this all apparently accomplishes is simplifying an "insanely compl=
>>icated" _compile-time_
>>>>> scheme that=2C I believe came from interaction between nested procedure=
>>s and inlining them.
>>>>>
>>>>> But it's at the cost of what I would call an insanely complicated _runt=
>>ime_ scheme.
>>>>>
>>>>> It undermined m3gdb's handling of static links=2C and I don't think it'=
>>s possible to fix
>>>>> with the current design of emitting debug info very early. The location=
>>s and target
>>>>> offsets of these things aren't know until later=2C and m3gdb really nee=
>>ds to know them.
>>>>>
>>>>>
>>>>> Jay K wrote:
>>>>>> What I meant regarding "static chain" was more like "does gcc already =
>>have support that we can use".
>>>>>> Don't any of the other languages need it already?
>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>
>>>>>> - Jay
>>>>>>
>>> = 		 	   		  

From mika at async.async.caltech.edu  Fri May 21 08:45:22 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 20 May 2010 23:45:22 -0700
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W62B5841AA922ECC333168E6E40@phx.gbl> 
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, , ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, , ,
	<4BF56D60.2000403@lcwb.coop>, ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>,
	<20100521053756.D74951A2094@async.async.caltech.edu>
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>
Message-ID: <20100521064522.93AAC1A2094@async.async.caltech.edu>

The Dragon Book is 

Aho, Sethi, Ullman.  Compilers: Principles, Techniques, and Tools.
Addison-Wesley, 1988.  Chapter 7, esp. Sec. 7.4.

   Mika

Jay K writes:
>
>Thanks for the reference!
>=20
>search for "Good Ideas=2C Through the Looking Glass"
>finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_o=
>rigFig.pdf"
>(I don't need to provide the link really.)
>=20
> - Jay
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Thu=2C 20 May 2010 22:37:56 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>>
>> As I recall it the "Dragon Book" has a whole section on this topic of
>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>> an expert=2C just remember reading it. Wirth also talks about it in his
>> "Good Ideas=2C Through the Looking Glass" (where he says the display
>> might be a pessimization).
>>
>> Mika
>>
>> Jay K writes:
>>>
>>>Maybe we can/should transform into one of the forms I show and dispense w=
>it=3D
>>>h any gcc support?
>>>At the cost of losing some "easy" optimization..of nested functions?
>>> "easy" as in=3D2C occurs even without -O2=3D2C but might occur with -O2?
>>>=3D20
>>>=3D20
>>>I know what you mean -- NT386 passes the static link in ecx.
>>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>=3D20
>>>=3D20
>>>Passing it as "just" another parameter might be less efficient=3D2C but o=
>k?
>>> And really=3D2C it'd only be less efficient on one architecture -- 32bit=
> x8=3D
>>>6.
>>> And maybe not all x86s -- depending on if some ABIs have a register base=
>d=3D
>>> calling convention.
>>>=3D20
>>>=3D20
>>>We don't need any actual ABI-compatibility with anything here=3D2C do we?
>>>=3D20
>>>=3D20
>>> - Jay
>>>
>>>
>>>----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Thu=3D2C 20 May 2010 22:22:46 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>
>>>> That is the standard formulation=3D2C but different architectures have =
>diff=3D
>>>erent optimised forms (passing static link in a register=3D2C etc.). In a=
>ny c=3D
>>>ase=3D2C gcc has its own weird way of doing things=3D2C which we mostly u=
>se=3D2C =3D
>>>but from which we need a little extra support (hence the small amount of =
>sp=3D
>>>ecial tailoring).
>>>>
>>>> On 20 May 2010=3D2C at 21:43=3D2C Jay K wrote:
>>>>
>>>>>
>>>>> Wierd. To me the model to follow is almost obvious. It should be obvio=
>us=3D
>>> to everyone and implemented the way I have in mind. :)
>>>>>
>>>>>
>>>>> The static link is an extra parameter.
>>>>> And=3D2C as such=3D2C also an extra local variable.
>>>>> You only need one.
>>>>> Each nesting level would follow another chain.
>>>>> Or you can pass each nesting level as an extra parameter.
>>>>> Or you can optimize and pass locals/parameters separately.
>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>
>>>>>
>>>>> Here=3D2C I worked it through:
>>>>>
>>>>>
>>>>>
>>>>> Why doesn't it just look something like this:
>>>>>
>>>>>
>>>>> nested:
>>>>>
>>>>> void F1(int a=3D2C int b)
>>>>> {
>>>>> int c =3D3D a + b=3D3B
>>>>>
>>>>> int f2()
>>>>> {
>>>>> int d =3D3D a + b=3D3B
>>>>>
>>>>> int f3()
>>>>> {
>>>>> return d + a + c=3D3B
>>>>> }
>>>>>
>>>>> return a + c + f3()=3D3B
>>>>> }
>>>>>
>>>>> return f2()=3D3B
>>>>> }
>>>>>
>>>>> not nested:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int d=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> f1_frame_t* f1=3D3B
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int c=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2)
>>>>> {
>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> int c =3D3D a + b=3D3B
>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> or=3D2C alernatively=3D2C almost the same=3D2C pass each chain as anot=
>her para=3D
>>>meter:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int d=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int c=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>> {
>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D2C f1)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> int c =3D3D a + b=3D3B
>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> This should be easily adapted to any function call convention/sequence=
>.
>>>>> e.g. even if parameters are passed in registers.
>>>>>
>>>>>
>>>>> And for that matter=3D2C why don't we just transform it to be like thi=
>s?
>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>>
>>>>> This form doesn't work?
>>>>>
>>>>>
>>>>> Isn't reasonably simple?
>>>>>
>>>>>
>>>>> Granted it might not be optimal. But it depends.
>>>>> You know=3D2C you can copy in the local/parameter values=3D2C but then=
> you h=3D
>>>ave
>>>>> to copy them out too. You can do analysis to show they aren't changed=
>=3D2C
>>>>> in which case no need to copy them out.
>>>>> Similarly you can pass the parameters as separate parameters=3D2C by a=
>ddre=3D
>>>ss
>>>>> if they are ever changed.
>>>>>
>>>>>
>>>>> A portable transform couldn't depend on adjacency of locals and parame=
>te=3D
>>>rs.
>>>>> It would have to either copy the parameters into the frame_t=3D2C or t=
>heir=3D
>>> addresses.
>>>>>
>>>>>
>>>>> A portable form couldn't get the frame by taking the address of a "ind=
>iv=3D
>>>idual" local.
>>>>>
>>>>>
>>>>> Here is portable form:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> int d=3D3B
>>>>> f1_frame_t* f1=3D3B
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>> typedef struct {
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> int c=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2)
>>>>> {
>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>> }
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> f2_frame_t f=3D3B
>>>>> f.f1 =3D3D f1=3D3B
>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3(&f)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> f1_frame_t f=3D3B
>>>>> f.a =3D3D a=3D3B
>>>>> f.b =3D3D b=3D3B
>>>>> f.c =3D3D a + b=3D3B
>>>>> return f2(&f)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> or:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> int d=3D3B
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> int c=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>> {
>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> f2_frame_t f=3D3B
>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3(&f=3D2C f1)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> f1_frame_t f=3D3B
>>>>> f.a =3D3D a=3D3B
>>>>> f.b =3D3D b=3D3B
>>>>> f.c =3D3D a + b=3D3B
>>>>> return f2(&f)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> Date: Thu=3D2C 20 May 2010 12:12:00 -0500
>>>>>> From: rodney_bates at lcwb.coop
>>>>>> To: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>
>>>>>> gcc even extends C with nested functions=3D2C and the support is ther=
>e fo=3D
>>>r that. We use it too.
>>>>>>
>>>>>> Beware: The runtime model is=3D2C IMO=3D2C bizarre. Definitely counte=
>rintui=3D
>>>tive and unlike anything
>>>>>> you will ever see elsewhere. There are two static links. One is used =
>fo=3D
>>>r the first step
>>>>>> in following a static chain and points to the expected place in the t=
>ar=3D
>>>get frame. The other
>>>>>> is used of subsequent steps in chain-following=3D2C and points to som=
>ewhe=3D
>>>re inside the target
>>>>>> frame that is dependent on the target procedure. It's the beginning o=
>f =3D
>>>a subrecord where
>>>>>> all the nonlocally-referenced variables are collected. The second sta=
>ti=3D
>>>c link is also
>>>>>> located in there. All the nonlocally-referenced variables and paramet=
>er=3D
>>>s are duplicated
>>>>>> in there too.
>>>>>>
>>>>>> I'm not sure I remembered these details exactly right. Maybe both lin=
>ks=3D
>>> point to the
>>>>>> subrecord=3D2C but one is located at a traditional procedure-independ=
>ent=3D
>>>=3D2C fixed location
>>>>>> in the frame=3D2C while the second is located in the subrecord. Also=
>=3D2C s=3D
>>>ometimes the first
>>>>>> static link value is kept in a register and never stored.
>>>>>>
>>>>>> What this all apparently accomplishes is simplifying an "insanely com=
>pl=3D
>>>icated" _compile-time_
>>>>>> scheme that=3D2C I believe came from interaction between nested proce=
>dure=3D
>>>s and inlining them.
>>>>>>
>>>>>> But it's at the cost of what I would call an insanely complicated _ru=
>nt=3D
>>>ime_ scheme.
>>>>>>
>>>>>> It undermined m3gdb's handling of static links=3D2C and I don't think=
> it'=3D
>>>s possible to fix
>>>>>> with the current design of emitting debug info very early. The locati=
>on=3D
>>>s and target
>>>>>> offsets of these things aren't know until later=3D2C and m3gdb really=
> nee=3D
>>>ds to know them.
>>>>>>
>>>>>>
>>>>>> Jay K wrote:
>>>>>>> What I meant regarding "static chain" was more like "does gcc alread=
>y =3D
>>>have support that we can use".
>>>>>>> Don't any of the other languages need it already?
>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>> =3D 		 	   		  =


From jay.krell at cornell.edu  Fri May 21 09:41:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 07:41:46 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <20100521064522.93AAC1A2094@async.async.caltech.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , ,
	,,<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , ,
	,,<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , ,
	,,<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, ,
	,,<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, ,
	,,<4BF56D60.2000403@lcwb.coop>,
	,,<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>,
	, , <AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>, ,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>, ,
	<20100521053756.D74951A2094@async.async.caltech.edu>,
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>,
	<20100521064522.93AAC1A2094@async.async.caltech.edu>
Message-ID: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>


Of course. I tried to read it as a teenager and got stuck on the automata stuff.
 
 
Wirth isn't 100% clear to me.
 He describes my two schemes.
 I think he throws out the second as an unimportant optimization.
 He criticizes the first as inefficient, granted.
 What I don't get is the static link in addition to the dynamic link.
 Perhaps I have not accounted for recursion.
 
 
Oh..I see..he is allowing to take the address of a nested function.
I didn't account for that.
I still don't understand all the arrow he draws for the static link, but
I do see that my scheme doesn't suffice.
Taking the address of a nested function..doesn't seem like a good idea.
Maybe I'm too C-minded.
 
 
My prototypical favorite Scheme example is:
 
 
(define (make-adder x)
   (define (add y) (+ x y))
   add)
 
 
(define add2 (make-adder 2))
(add2 3) => 5
 
 
but Modula-3 doesn't allow for that anyway..
 
Still, we make "closures": tuple{-1, function pointer, frame pointer}
before calling a pointer, we check if it points to -1, and if so
we call function pointer with frame pointer as the link.
 
 
And then I guess, you might have something like this?
 
 
 
int F1(int a, int b, int (*F)())
{
  int F2()
  {
    return a + b;
  }
 
  if (F != NULL)
   return F();
 
  return F1(a - 1, b - 1, &F2);
 
}
 
 
F(1, 2, NULL) => 3
 
 
Though that doesn't demonstrate the generality perhaps.
 
 
Taking the address of a nested function seems dubious.
 
 
My "favorite" bit of Schema:
 
(define (make-adder x)
   (define (add y) (+ x y))
   add)
 
 
(define add2 (make-adder 2))
 
(add2 3) => 3
 
 
But we don't allow that sort of thing -- frames are always stack allocated.
 
 
 
 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Thu, 20 May 2010 23:45:22 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> The Dragon Book is
>
> Aho, Sethi, Ullman. Compilers: Principles, Techniques, and Tools.
> Addison-Wesley, 1988. Chapter 7, esp. Sec. 7.4.
>
> Mika
>
> Jay K writes:
>>
>>Thanks for the reference!
>>=20
>>search for "Good Ideas=2C Through the Looking Glass"
>>finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_o=
>>rigFig.pdf"
>>(I don't need to provide the link really.)
>>=20
>> - Jay
>>
>>----------------------------------------
>>> To: jay.krell at cornell.edu
>>> Date: Thu=2C 20 May 2010 22:37:56 -0700
>>> From: mika at async.async.caltech.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>>
>>> As I recall it the "Dragon Book" has a whole section on this topic of
>>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>>> an expert=2C just remember reading it. Wirth also talks about it in his
>>> "Good Ideas=2C Through the Looking Glass" (where he says the display
>>> might be a pessimization).
>>>
>>> Mika
>>>
>>> Jay K writes:
>>>>
>>>>Maybe we can/should transform into one of the forms I show and dispense w=
>>it=3D
>>>>h any gcc support?
>>>>At the cost of losing some "easy" optimization..of nested functions?
>>>> "easy" as in=3D2C occurs even without -O2=3D2C but might occur with -O2?
>>>>=3D20
>>>>=3D20
>>>>I know what you mean -- NT386 passes the static link in ecx.
>>>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>>=3D20
>>>>=3D20
>>>>Passing it as "just" another parameter might be less efficient=3D2C but o=
>>k?
>>>> And really=3D2C it'd only be less efficient on one architecture -- 32bit=
>> x8=3D
>>>>6.
>>>> And maybe not all x86s -- depending on if some ABIs have a register base=
>>d=3D
>>>> calling convention.
>>>>=3D20
>>>>=3D20
>>>>We don't need any actual ABI-compatibility with anything here=3D2C do we?
>>>>=3D20
>>>>=3D20
>>>> - Jay
>>>>
>>>>
>>>>----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Thu=3D2C 20 May 2010 22:22:46 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>
>>>>> That is the standard formulation=3D2C but different architectures have =
>>diff=3D
>>>>erent optimised forms (passing static link in a register=3D2C etc.). In a=
>>ny c=3D
>>>>ase=3D2C gcc has its own weird way of doing things=3D2C which we mostly u=
>>se=3D2C =3D
>>>>but from which we need a little extra support (hence the small amount of =
>>sp=3D
>>>>ecial tailoring).
>>>>>
>>>>> On 20 May 2010=3D2C at 21:43=3D2C Jay K wrote:
>>>>>
>>>>>>
>>>>>> Wierd. To me the model to follow is almost obvious. It should be obvio=
>>us=3D
>>>> to everyone and implemented the way I have in mind. :)
>>>>>>
>>>>>>
>>>>>> The static link is an extra parameter.
>>>>>> And=3D2C as such=3D2C also an extra local variable.
>>>>>> You only need one.
>>>>>> Each nesting level would follow another chain.
>>>>>> Or you can pass each nesting level as an extra parameter.
>>>>>> Or you can optimize and pass locals/parameters separately.
>>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>>
>>>>>>
>>>>>> Here=3D2C I worked it through:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Why doesn't it just look something like this:
>>>>>>
>>>>>>
>>>>>> nested:
>>>>>>
>>>>>> void F1(int a=3D2C int b)
>>>>>> {
>>>>>> int c =3D3D a + b=3D3B
>>>>>>
>>>>>> int f2()
>>>>>> {
>>>>>> int d =3D3D a + b=3D3B
>>>>>>
>>>>>> int f3()
>>>>>> {
>>>>>> return d + a + c=3D3B
>>>>>> }
>>>>>>
>>>>>> return a + c + f3()=3D3B
>>>>>> }
>>>>>>
>>>>>> return f2()=3D3B
>>>>>> }
>>>>>>
>>>>>> not nested:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int d=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> f1_frame_t* f1=3D3B
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int c=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2)
>>>>>> {
>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> int c =3D3D a + b=3D3B
>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> or=3D2C alernatively=3D2C almost the same=3D2C pass each chain as anot=
>>her para=3D
>>>>meter:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int d=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int c=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>> {
>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D2C f1)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> int c =3D3D a + b=3D3B
>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> This should be easily adapted to any function call convention/sequence=
>>.
>>>>>> e.g. even if parameters are passed in registers.
>>>>>>
>>>>>>
>>>>>> And for that matter=3D2C why don't we just transform it to be like thi=
>>s?
>>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>>
>>>>>>
>>>>>> Am I missing something?
>>>>>>
>>>>>>
>>>>>> This form doesn't work?
>>>>>>
>>>>>>
>>>>>> Isn't reasonably simple?
>>>>>>
>>>>>>
>>>>>> Granted it might not be optimal. But it depends.
>>>>>> You know=3D2C you can copy in the local/parameter values=3D2C but then=
>> you h=3D
>>>>ave
>>>>>> to copy them out too. You can do analysis to show they aren't changed=
>>=3D2C
>>>>>> in which case no need to copy them out.
>>>>>> Similarly you can pass the parameters as separate parameters=3D2C by a=
>>ddre=3D
>>>>ss
>>>>>> if they are ever changed.
>>>>>>
>>>>>>
>>>>>> A portable transform couldn't depend on adjacency of locals and parame=
>>te=3D
>>>>rs.
>>>>>> It would have to either copy the parameters into the frame_t=3D2C or t=
>>heir=3D
>>>> addresses.
>>>>>>
>>>>>>
>>>>>> A portable form couldn't get the frame by taking the address of a "ind=
>>iv=3D
>>>>idual" local.
>>>>>>
>>>>>>
>>>>>> Here is portable form:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> int d=3D3B
>>>>>> f1_frame_t* f1=3D3B
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>> typedef struct {
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> int c=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2)
>>>>>> {
>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> f2_frame_t f=3D3B
>>>>>> f.f1 =3D3D f1=3D3B
>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3(&f)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> f1_frame_t f=3D3B
>>>>>> f.a =3D3D a=3D3B
>>>>>> f.b =3D3D b=3D3B
>>>>>> f.c =3D3D a + b=3D3B
>>>>>> return f2(&f)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> or:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> int d=3D3B
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> int c=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>> {
>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> f2_frame_t f=3D3B
>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3(&f=3D2C f1)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> f1_frame_t f=3D3B
>>>>>> f.a =3D3D a=3D3B
>>>>>> f.b =3D3D b=3D3B
>>>>>> f.c =3D3D a + b=3D3B
>>>>>> return f2(&f)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> Date: Thu=3D2C 20 May 2010 12:12:00 -0500
>>>>>>> From: rodney_bates at lcwb.coop
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>>
>>>>>>> gcc even extends C with nested functions=3D2C and the support is ther=
>>e fo=3D
>>>>r that. We use it too.
>>>>>>>
>>>>>>> Beware: The runtime model is=3D2C IMO=3D2C bizarre. Definitely counte=
>>rintui=3D
>>>>tive and unlike anything
>>>>>>> you will ever see elsewhere. There are two static links. One is used =
>>fo=3D
>>>>r the first step
>>>>>>> in following a static chain and points to the expected place in the t=
>>ar=3D
>>>>get frame. The other
>>>>>>> is used of subsequent steps in chain-following=3D2C and points to som=
>>ewhe=3D
>>>>re inside the target
>>>>>>> frame that is dependent on the target procedure. It's the beginning o=
>>f =3D
>>>>a subrecord where
>>>>>>> all the nonlocally-referenced variables are collected. The second sta=
>>ti=3D
>>>>c link is also
>>>>>>> located in there. All the nonlocally-referenced variables and paramet=
>>er=3D
>>>>s are duplicated
>>>>>>> in there too.
>>>>>>>
>>>>>>> I'm not sure I remembered these details exactly right. Maybe both lin=
>>ks=3D
>>>> point to the
>>>>>>> subrecord=3D2C but one is located at a traditional procedure-independ=
>>ent=3D
>>>>=3D2C fixed location
>>>>>>> in the frame=3D2C while the second is located in the subrecord. Also=
>>=3D2C s=3D
>>>>ometimes the first
>>>>>>> static link value is kept in a register and never stored.
>>>>>>>
>>>>>>> What this all apparently accomplishes is simplifying an "insanely com=
>>pl=3D
>>>>icated" _compile-time_
>>>>>>> scheme that=3D2C I believe came from interaction between nested proce=
>>dure=3D
>>>>s and inlining them.
>>>>>>>
>>>>>>> But it's at the cost of what I would call an insanely complicated _ru=
>>nt=3D
>>>>ime_ scheme.
>>>>>>>
>>>>>>> It undermined m3gdb's handling of static links=3D2C and I don't think=
>> it'=3D
>>>>s possible to fix
>>>>>>> with the current design of emitting debug info very early. The locati=
>>on=3D
>>>>s and target
>>>>>>> offsets of these things aren't know until later=3D2C and m3gdb really=
>> nee=3D
>>>>ds to know them.
>>>>>>>
>>>>>>>
>>>>>>> Jay K wrote:
>>>>>>>> What I meant regarding "static chain" was more like "does gcc alread=
>>y =3D
>>>>have support that we can use".
>>>>>>>> Don't any of the other languages need it already?
>>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>> =3D = 		 	   		  

From mika at async.async.caltech.edu  Fri May 21 09:44:59 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 21 May 2010 00:44:59 -0700
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl> 
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , , , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , , , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, , , ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, , , ,
	<4BF56D60.2000403@lcwb.coop>, , ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, , ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>, ,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>, ,
	<20100521053756.D74951A2094@async.async.caltech.edu>,
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>,
	<20100521064522.93AAC1A2094@async.async.caltech.edu>
	<COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
Message-ID: <20100521074459.BF5041A2061@async.async.caltech.edu>


In Modula-3 you can pass a nested function in a function call.  It can
be quite useful but it's broken in PM3 so I never use it.

I've been meaning to write an optimistic Scheme compiler that uses tricks
with nested functions passed like that to allocate closures on demand...

(With nested functions, you can essentially set up a mechanism to jump
back up the stack, of course by doubling the recursion depth, and that
you could use to copy the stack into heap memory... something like that)

    Mika

Jay K writes:
>
>Of course. I tried to read it as a teenager and got stuck on the automata s=
>tuff.
>=20
>=20
>Wirth isn't 100% clear to me.
> He describes my two schemes.
> I think he throws out the second as an unimportant optimization.
> He criticizes the first as inefficient=2C granted.
> What I don't get is the static link in addition to the dynamic link.
> Perhaps I have not accounted for recursion.
>=20
>=20
>Oh..I see..he is allowing to take the address of a nested function.
>I didn't account for that.
>I still don't understand all the arrow he draws for the static link=2C but
>I do see that my scheme doesn't suffice.
>Taking the address of a nested function..doesn't seem like a good idea.
>Maybe I'm too C-minded.
>=20
>=20
>My prototypical favorite Scheme example is:
>=20
>=20
>(define (make-adder x)
>   (define (add y) (+ x y))
>   add)
>=20
>=20
>(define add2 (make-adder 2))
>(add2 3) =3D> 5
>=20
>=20
>but Modula-3 doesn't allow for that anyway..
>=20
>Still=2C we make "closures": tuple{-1=2C function pointer=2C frame pointer}
>before calling a pointer=2C we check if it points to -1=2C and if so
>we call function pointer with frame pointer as the link.
>=20
>=20
>And then I guess=2C you might have something like this?
>=20
>=20
>=20
>int F1(int a=2C int b=2C int (*F)())
>{
>  int F2()
>  {
>    return a + b=3B
>  }
>=20
>  if (F !=3D NULL)
>   return F()=3B
>=20
>  return F1(a - 1=2C b - 1=2C &F2)=3B
>=20
>}
>=20
>=20
>F(1=2C 2=2C NULL) =3D> 3
>=20
>=20
>Though that doesn't demonstrate the generality perhaps.
>=20
>=20
>Taking the address of a nested function seems dubious.
>=20
>=20
>My "favorite" bit of Schema:
>=20
>(define (make-adder x)
>   (define (add y) (+ x y))
>   add)
>=20
>=20
>(define add2 (make-adder 2))
>=20
>(add2 3) =3D> 3
>=20
>=20
>But we don't allow that sort of thing -- frames are always stack allocated.
>=20
>=20
>=20
> - Jay
>
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Thu=2C 20 May 2010 23:45:22 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>> The Dragon Book is
>>
>> Aho=2C Sethi=2C Ullman. Compilers: Principles=2C Techniques=2C and Tools.
>> Addison-Wesley=2C 1988. Chapter 7=2C esp. Sec. 7.4.
>>
>> Mika
>>
>> Jay K writes:
>>>
>>>Thanks for the reference!
>>>=3D20
>>>search for "Good Ideas=3D2C Through the Looking Glass"
>>>finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas=
>_o=3D
>>>rigFig.pdf"
>>>(I don't need to provide the link really.)
>>>=3D20
>>> - Jay
>>>
>>>----------------------------------------
>>>> To: jay.krell at cornell.edu
>>>> Date: Thu=3D2C 20 May 2010 22:37:56 -0700
>>>> From: mika at async.async.caltech.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>
>>>>
>>>> As I recall it the "Dragon Book" has a whole section on this topic of
>>>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>>>> an expert=3D2C just remember reading it. Wirth also talks about it in h=
>is
>>>> "Good Ideas=3D2C Through the Looking Glass" (where he says the display
>>>> might be a pessimization).
>>>>
>>>> Mika
>>>>
>>>> Jay K writes:
>>>>>
>>>>>Maybe we can/should transform into one of the forms I show and dispense=
> w=3D
>>>it=3D3D
>>>>>h any gcc support?
>>>>>At the cost of losing some "easy" optimization..of nested functions?
>>>>> "easy" as in=3D3D2C occurs even without -O2=3D3D2C but might occur wit=
>h -O2?
>>>>>=3D3D20
>>>>>=3D3D20
>>>>>I know what you mean -- NT386 passes the static link in ecx.
>>>>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>>>=3D3D20
>>>>>=3D3D20
>>>>>Passing it as "just" another parameter might be less efficient=3D3D2C b=
>ut o=3D
>>>k?
>>>>> And really=3D3D2C it'd only be less efficient on one architecture -- 3=
>2bit=3D
>>> x8=3D3D
>>>>>6.
>>>>> And maybe not all x86s -- depending on if some ABIs have a register ba=
>se=3D
>>>d=3D3D
>>>>> calling convention.
>>>>>=3D3D20
>>>>>=3D3D20
>>>>>We don't need any actual ABI-compatibility with anything here=3D3D2C do=
> we?
>>>>>=3D3D20
>>>>>=3D3D20
>>>>> - Jay
>>>>>
>>>>>
>>>>>----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Thu=3D3D2C 20 May 2010 22:22:46 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>
>>>>>> That is the standard formulation=3D3D2C but different architectures h=
>ave =3D
>>>diff=3D3D
>>>>>erent optimised forms (passing static link in a register=3D3D2C etc.). =
>In a=3D
>>>ny c=3D3D
>>>>>ase=3D3D2C gcc has its own weird way of doing things=3D3D2C which we mo=
>stly u=3D
>>>se=3D3D2C =3D3D
>>>>>but from which we need a little extra support (hence the small amount o=
>f =3D
>>>sp=3D3D
>>>>>ecial tailoring).
>>>>>>
>>>>>> On 20 May 2010=3D3D2C at 21:43=3D3D2C Jay K wrote:
>>>>>>
>>>>>>>
>>>>>>> Wierd. To me the model to follow is almost obvious. It should be obv=
>io=3D
>>>us=3D3D
>>>>> to everyone and implemented the way I have in mind. :)
>>>>>>>
>>>>>>>
>>>>>>> The static link is an extra parameter.
>>>>>>> And=3D3D2C as such=3D3D2C also an extra local variable.
>>>>>>> You only need one.
>>>>>>> Each nesting level would follow another chain.
>>>>>>> Or you can pass each nesting level as an extra parameter.
>>>>>>> Or you can optimize and pass locals/parameters separately.
>>>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>>>
>>>>>>>
>>>>>>> Here=3D3D2C I worked it through:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Why doesn't it just look something like this:
>>>>>>>
>>>>>>>
>>>>>>> nested:
>>>>>>>
>>>>>>> void F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D3D a + b=3D3D3B
>>>>>>>
>>>>>>> int f2()
>>>>>>> {
>>>>>>> int d =3D3D3D a + b=3D3D3B
>>>>>>>
>>>>>>> int f3()
>>>>>>> {
>>>>>>> return d + a + c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> return a + c + f3()=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> return f2()=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> not nested:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> f1_frame_t* f1=3D3D3B
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D3D a + b=3D3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> or=3D3D2C alernatively=3D3D2C almost the same=3D3D2C pass each chain=
> as anot=3D
>>>her para=3D3D
>>>>>meter:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2=3D3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D3D2C f1)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D3D a + b=3D3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> This should be easily adapted to any function call convention/sequen=
>ce=3D
>>>.
>>>>>>> e.g. even if parameters are passed in registers.
>>>>>>>
>>>>>>>
>>>>>>> And for that matter=3D3D2C why don't we just transform it to be like=
> thi=3D
>>>s?
>>>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>>>
>>>>>>>
>>>>>>> Am I missing something?
>>>>>>>
>>>>>>>
>>>>>>> This form doesn't work?
>>>>>>>
>>>>>>>
>>>>>>> Isn't reasonably simple?
>>>>>>>
>>>>>>>
>>>>>>> Granted it might not be optimal. But it depends.
>>>>>>> You know=3D3D2C you can copy in the local/parameter values=3D3D2C bu=
>t then=3D
>>> you h=3D3D
>>>>>ave
>>>>>>> to copy them out too. You can do analysis to show they aren't change=
>d=3D
>>>=3D3D2C
>>>>>>> in which case no need to copy them out.
>>>>>>> Similarly you can pass the parameters as separate parameters=3D3D2C =
>by a=3D
>>>ddre=3D3D
>>>>>ss
>>>>>>> if they are ever changed.
>>>>>>>
>>>>>>>
>>>>>>> A portable transform couldn't depend on adjacency of locals and para=
>me=3D
>>>te=3D3D
>>>>>rs.
>>>>>>> It would have to either copy the parameters into the frame_t=3D3D2C =
>or t=3D
>>>heir=3D3D
>>>>> addresses.
>>>>>>>
>>>>>>>
>>>>>>> A portable form couldn't get the frame by taking the address of a "i=
>nd=3D
>>>iv=3D3D
>>>>>idual" local.
>>>>>>>
>>>>>>>
>>>>>>> Here is portable form:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int d=3D3D3B
>>>>>>> f1_frame_t* f1=3D3D3B
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> int c=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3D3B
>>>>>>> f.f1 =3D3D3D f1=3D3D3B
>>>>>>> f.d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3(&f)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3D3B
>>>>>>> f.a =3D3D3D a=3D3D3B
>>>>>>> f.b =3D3D3D b=3D3D3B
>>>>>>> f.c =3D3D3D a + b=3D3D3B
>>>>>>> return f2(&f)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> or:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int d=3D3D3B
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> int c=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2=3D3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3D3B
>>>>>>> f.d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3(&f=3D3D2C f1)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3D3B
>>>>>>> f.a =3D3D3D a=3D3D3B
>>>>>>> f.b =3D3D3D b=3D3D3B
>>>>>>> f.c =3D3D3D a + b=3D3D3B
>>>>>>> return f2(&f)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> Date: Thu=3D3D2C 20 May 2010 12:12:00 -0500
>>>>>>>> From: rodney_bates at lcwb.coop
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>>>
>>>>>>>> gcc even extends C with nested functions=3D3D2C and the support is =
>ther=3D
>>>e fo=3D3D
>>>>>r that. We use it too.
>>>>>>>>
>>>>>>>> Beware: The runtime model is=3D3D2C IMO=3D3D2C bizarre. Definitely =
>counte=3D
>>>rintui=3D3D
>>>>>tive and unlike anything
>>>>>>>> you will ever see elsewhere. There are two static links. One is use=
>d =3D
>>>fo=3D3D
>>>>>r the first step
>>>>>>>> in following a static chain and points to the expected place in the=
> t=3D
>>>ar=3D3D
>>>>>get frame. The other
>>>>>>>> is used of subsequent steps in chain-following=3D3D2C and points to=
> som=3D
>>>ewhe=3D3D
>>>>>re inside the target
>>>>>>>> frame that is dependent on the target procedure. It's the beginning=
> o=3D
>>>f =3D3D
>>>>>a subrecord where
>>>>>>>> all the nonlocally-referenced variables are collected. The second s=
>ta=3D
>>>ti=3D3D
>>>>>c link is also
>>>>>>>> located in there. All the nonlocally-referenced variables and param=
>et=3D
>>>er=3D3D
>>>>>s are duplicated
>>>>>>>> in there too.
>>>>>>>>
>>>>>>>> I'm not sure I remembered these details exactly right. Maybe both l=
>in=3D
>>>ks=3D3D
>>>>> point to the
>>>>>>>> subrecord=3D3D2C but one is located at a traditional procedure-inde=
>pend=3D
>>>ent=3D3D
>>>>>=3D3D2C fixed location
>>>>>>>> in the frame=3D3D2C while the second is located in the subrecord. A=
>lso=3D
>>>=3D3D2C s=3D3D
>>>>>ometimes the first
>>>>>>>> static link value is kept in a register and never stored.
>>>>>>>>
>>>>>>>> What this all apparently accomplishes is simplifying an "insanely c=
>om=3D
>>>pl=3D3D
>>>>>icated" _compile-time_
>>>>>>>> scheme that=3D3D2C I believe came from interaction between nested p=
>roce=3D
>>>dure=3D3D
>>>>>s and inlining them.
>>>>>>>>
>>>>>>>> But it's at the cost of what I would call an insanely complicated _=
>ru=3D
>>>nt=3D3D
>>>>>ime_ scheme.
>>>>>>>>
>>>>>>>> It undermined m3gdb's handling of static links=3D3D2C and I don't t=
>hink=3D
>>> it'=3D3D
>>>>>s possible to fix
>>>>>>>> with the current design of emitting debug info very early. The loca=
>ti=3D
>>>on=3D3D
>>>>>s and target
>>>>>>>> offsets of these things aren't know until later=3D3D2C and m3gdb re=
>ally=3D
>>> nee=3D3D
>>>>>ds to know them.
>>>>>>>>
>>>>>>>>
>>>>>>>> Jay K wrote:
>>>>>>>>> What I meant regarding "static chain" was more like "does gcc alre=
>ad=3D
>>>y =3D3D
>>>>>have support that we can use".
>>>>>>>>> Don't any of the other languages need it already?
>>>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>> =3D3D =3D 		 	   		  =


From hendrik at topoi.pooq.com  Fri May 21 08:59:09 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 21 May 2010 02:59:09 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
References: <20100521064522.93AAC1A2094@async.async.caltech.edu>
	<COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
Message-ID: <20100521065909.GA27981@topoi.pooq.com>

On Fri, May 21, 2010 at 07:41:46AM +0000, Jay K wrote:
> 
> Oh..I see..he is allowing to take the address of a nested function.
> I didn't account for that.
> I still don't understand all the arrow he draws for the static link, but
> I do see that my scheme doesn't suffice.
> Taking the address of a nested function..doesn't seem like a good idea.

Works fine as long as you only use it within other nested stuff.  Very 
useful.  It's the way call-by-name in Algol 60 was implemented.  And if 
you were to put the stack on the heap and garbage-collect it (which 
can cost a lot (Scheme does this, not recommended for Modula 3)), you 
don't need the nesting restriction.

> Maybe I'm too C-minded.

-- hendrik



From jay.krell at cornell.edu  Fri May 21 14:54:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 12:54:35 +0000
Subject: [M3devel] RC5?
Message-ID: <COL101-W38D3ADE3E3D08C7CDE0549E6E40@phx.gbl>


RC5 packages have been here a month: http://www.opencm3.net/releng/download.html

Any users?

?- Jay





 		 	   		  

From hosking at cs.purdue.edu  Fri May 21 19:08:02 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 21 May 2010 13:08:02 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , , , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , , , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, , , ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, , , ,
	<4BF56D60.2000403@lcwb.coop>, , ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, , ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>, ,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>, ,
	<20100521053756.D74951A2094@async.async.caltech.edu>,
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>,
	<20100521064522.93AAC1A2094@async.async.caltech.edu>
	<COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
Message-ID: <A5424DAE-BAB3-456A-B059-82FAF82EE986@cs.purdue.edu>

We don't want to bypass the gcc support.
It works well with register allocation, etc.


On 21 May 2010, at 03:41, Jay K wrote:

> 
> Of course. I tried to read it as a teenager and got stuck on the automata stuff.
> 
> 
> Wirth isn't 100% clear to me.
> He describes my two schemes.
> I think he throws out the second as an unimportant optimization.
> He criticizes the first as inefficient, granted.
> What I don't get is the static link in addition to the dynamic link.
> Perhaps I have not accounted for recursion.
> 
> 
> Oh..I see..he is allowing to take the address of a nested function.
> I didn't account for that.
> I still don't understand all the arrow he draws for the static link, but
> I do see that my scheme doesn't suffice.
> Taking the address of a nested function..doesn't seem like a good idea.
> Maybe I'm too C-minded.
> 
> 
> My prototypical favorite Scheme example is:
> 
> 
> (define (make-adder x)
>   (define (add y) (+ x y))
>   add)
> 
> 
> (define add2 (make-adder 2))
> (add2 3) => 5
> 
> 
> but Modula-3 doesn't allow for that anyway..
> 
> Still, we make "closures": tuple{-1, function pointer, frame pointer}
> before calling a pointer, we check if it points to -1, and if so
> we call function pointer with frame pointer as the link.
> 
> 
> And then I guess, you might have something like this?
> 
> 
> 
> int F1(int a, int b, int (*F)())
> {
>  int F2()
>  {
>    return a + b;
>  }
> 
>  if (F != NULL)
>   return F();
> 
>  return F1(a - 1, b - 1, &F2);
> 
> }
> 
> 
> F(1, 2, NULL) => 3
> 
> 
> Though that doesn't demonstrate the generality perhaps.
> 
> 
> Taking the address of a nested function seems dubious.
> 
> 
> My "favorite" bit of Schema:
> 
> (define (make-adder x)
>   (define (add y) (+ x y))
>   add)
> 
> 
> (define add2 (make-adder 2))
> 
> (add2 3) => 3
> 
> 
> But we don't allow that sort of thing -- frames are always stack allocated.
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Thu, 20 May 2010 23:45:22 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> The Dragon Book is
>> 
>> Aho, Sethi, Ullman. Compilers: Principles, Techniques, and Tools.
>> Addison-Wesley, 1988. Chapter 7, esp. Sec. 7.4.
>> 
>> Mika
>> 
>> Jay K writes:
>>> 
>>> Thanks for the reference!
>>> =20
>>> search for "Good Ideas=2C Through the Looking Glass"
>>> finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_o=
>>> rigFig.pdf"
>>> (I don't need to provide the link really.)
>>> =20
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> To: jay.krell at cornell.edu
>>>> Date: Thu=2C 20 May 2010 22:37:56 -0700
>>>> From: mika at async.async.caltech.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>> 
>>>> 
>>>> As I recall it the "Dragon Book" has a whole section on this topic of
>>>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>>>> an expert=2C just remember reading it. Wirth also talks about it in his
>>>> "Good Ideas=2C Through the Looking Glass" (where he says the display
>>>> might be a pessimization).
>>>> 
>>>> Mika
>>>> 
>>>> Jay K writes:
>>>>> 
>>>>> Maybe we can/should transform into one of the forms I show and dispense w=
>>> it=3D
>>>>> h any gcc support?
>>>>> At the cost of losing some "easy" optimization..of nested functions?
>>>>> "easy" as in=3D2C occurs even without -O2=3D2C but might occur with -O2?
>>>>> =3D20
>>>>> =3D20
>>>>> I know what you mean -- NT386 passes the static link in ecx.
>>>>> This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>>> =3D20
>>>>> =3D20
>>>>> Passing it as "just" another parameter might be less efficient=3D2C but o=
>>> k?
>>>>> And really=3D2C it'd only be less efficient on one architecture -- 32bit=
>>> x8=3D
>>>>> 6.
>>>>> And maybe not all x86s -- depending on if some ABIs have a register base=
>>> d=3D
>>>>> calling convention.
>>>>> =3D20
>>>>> =3D20
>>>>> We don't need any actual ABI-compatibility with anything here=3D2C do we?
>>>>> =3D20
>>>>> =3D20
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Thu=3D2C 20 May 2010 22:22:46 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>> 
>>>>>> That is the standard formulation=3D2C but different architectures have =
>>> diff=3D
>>>>> erent optimised forms (passing static link in a register=3D2C etc.). In a=
>>> ny c=3D
>>>>> ase=3D2C gcc has its own weird way of doing things=3D2C which we mostly u=
>>> se=3D2C =3D
>>>>> but from which we need a little extra support (hence the small amount of =
>>> sp=3D
>>>>> ecial tailoring).
>>>>>> 
>>>>>> On 20 May 2010=3D2C at 21:43=3D2C Jay K wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Wierd. To me the model to follow is almost obvious. It should be obvio=
>>> us=3D
>>>>> to everyone and implemented the way I have in mind. :)
>>>>>>> 
>>>>>>> 
>>>>>>> The static link is an extra parameter.
>>>>>>> And=3D2C as such=3D2C also an extra local variable.
>>>>>>> You only need one.
>>>>>>> Each nesting level would follow another chain.
>>>>>>> Or you can pass each nesting level as an extra parameter.
>>>>>>> Or you can optimize and pass locals/parameters separately.
>>>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>>> 
>>>>>>> 
>>>>>>> Here=3D2C I worked it through:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Why doesn't it just look something like this:
>>>>>>> 
>>>>>>> 
>>>>>>> nested:
>>>>>>> 
>>>>>>> void F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D a + b=3D3B
>>>>>>> 
>>>>>>> int f2()
>>>>>>> {
>>>>>>> int d =3D3D a + b=3D3B
>>>>>>> 
>>>>>>> int f3()
>>>>>>> {
>>>>>>> return d + a + c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> return a + c + f3()=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> return f2()=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> not nested:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> f1_frame_t* f1=3D3B
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D a + b=3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> or=3D2C alernatively=3D2C almost the same=3D2C pass each chain as anot=
>>> her para=3D
>>>>> meter:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D2C f1)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D a + b=3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> This should be easily adapted to any function call convention/sequence=
>>> .
>>>>>>> e.g. even if parameters are passed in registers.
>>>>>>> 
>>>>>>> 
>>>>>>> And for that matter=3D2C why don't we just transform it to be like thi=
>>> s?
>>>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>>> 
>>>>>>> 
>>>>>>> Am I missing something?
>>>>>>> 
>>>>>>> 
>>>>>>> This form doesn't work?
>>>>>>> 
>>>>>>> 
>>>>>>> Isn't reasonably simple?
>>>>>>> 
>>>>>>> 
>>>>>>> Granted it might not be optimal. But it depends.
>>>>>>> You know=3D2C you can copy in the local/parameter values=3D2C but then=
>>> you h=3D
>>>>> ave
>>>>>>> to copy them out too. You can do analysis to show they aren't changed=
>>> =3D2C
>>>>>>> in which case no need to copy them out.
>>>>>>> Similarly you can pass the parameters as separate parameters=3D2C by a=
>>> ddre=3D
>>>>> ss
>>>>>>> if they are ever changed.
>>>>>>> 
>>>>>>> 
>>>>>>> A portable transform couldn't depend on adjacency of locals and parame=
>>> te=3D
>>>>> rs.
>>>>>>> It would have to either copy the parameters into the frame_t=3D2C or t=
>>> heir=3D
>>>>> addresses.
>>>>>>> 
>>>>>>> 
>>>>>>> A portable form couldn't get the frame by taking the address of a "ind=
>>> iv=3D
>>>>> idual" local.
>>>>>>> 
>>>>>>> 
>>>>>>> Here is portable form:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int d=3D3B
>>>>>>> f1_frame_t* f1=3D3B
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> int c=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3B
>>>>>>> f.f1 =3D3D f1=3D3B
>>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3(&f)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3B
>>>>>>> f.a =3D3D a=3D3B
>>>>>>> f.b =3D3D b=3D3B
>>>>>>> f.c =3D3D a + b=3D3B
>>>>>>> return f2(&f)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> or:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int d=3D3B
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> int c=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3B
>>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3(&f=3D2C f1)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3B
>>>>>>> f.a =3D3D a=3D3B
>>>>>>> f.b =3D3D b=3D3B
>>>>>>> f.c =3D3D a + b=3D3B
>>>>>>> return f2(&f)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> Date: Thu=3D2C 20 May 2010 12:12:00 -0500
>>>>>>>> From: rodney_bates at lcwb.coop
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>>> 
>>>>>>>> gcc even extends C with nested functions=3D2C and the support is ther=
>>> e fo=3D
>>>>> r that. We use it too.
>>>>>>>> 
>>>>>>>> Beware: The runtime model is=3D2C IMO=3D2C bizarre. Definitely counte=
>>> rintui=3D
>>>>> tive and unlike anything
>>>>>>>> you will ever see elsewhere. There are two static links. One is used =
>>> fo=3D
>>>>> r the first step
>>>>>>>> in following a static chain and points to the expected place in the t=
>>> ar=3D
>>>>> get frame. The other
>>>>>>>> is used of subsequent steps in chain-following=3D2C and points to som=
>>> ewhe=3D
>>>>> re inside the target
>>>>>>>> frame that is dependent on the target procedure. It's the beginning o=
>>> f =3D
>>>>> a subrecord where
>>>>>>>> all the nonlocally-referenced variables are collected. The second sta=
>>> ti=3D
>>>>> c link is also
>>>>>>>> located in there. All the nonlocally-referenced variables and paramet=
>>> er=3D
>>>>> s are duplicated
>>>>>>>> in there too.
>>>>>>>> 
>>>>>>>> I'm not sure I remembered these details exactly right. Maybe both lin=
>>> ks=3D
>>>>> point to the
>>>>>>>> subrecord=3D2C but one is located at a traditional procedure-independ=
>>> ent=3D
>>>>> =3D2C fixed location
>>>>>>>> in the frame=3D2C while the second is located in the subrecord. Also=
>>> =3D2C s=3D
>>>>> ometimes the first
>>>>>>>> static link value is kept in a register and never stored.
>>>>>>>> 
>>>>>>>> What this all apparently accomplishes is simplifying an "insanely com=
>>> pl=3D
>>>>> icated" _compile-time_
>>>>>>>> scheme that=3D2C I believe came from interaction between nested proce=
>>> dure=3D
>>>>> s and inlining them.
>>>>>>>> 
>>>>>>>> But it's at the cost of what I would call an insanely complicated _ru=
>>> nt=3D
>>>>> ime_ scheme.
>>>>>>>> 
>>>>>>>> It undermined m3gdb's handling of static links=3D2C and I don't think=
>>> it'=3D
>>>>> s possible to fix
>>>>>>>> with the current design of emitting debug info very early. The locati=
>>> on=3D
>>>>> s and target
>>>>>>>> offsets of these things aren't know until later=3D2C and m3gdb really=
>>> nee=3D
>>>>> ds to know them.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Jay K wrote:
>>>>>>>>> What I meant regarding "static chain" was more like "does gcc alread=
>>> y =3D
>>>>> have support that we can use".
>>>>>>>>> Don't any of the other languages need it already?
>>>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>>> 
>>>>>>>>> - Jay
>>>>>>>>> 
>>>>>> =3D = 		 	   		  



From rodney_bates at lcwb.coop  Fri May 21 21:45:32 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 21 May 2010 14:45:32 -0500
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	<4BF56D60.2000403@lcwb.coop>
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
Message-ID: <4BF6E2DC.3090601@lcwb.coop>

I have no quarrels with you there, Jay.  I'm not advocating it, just
reporting what I know about how gcc does it.

Jay K wrote:
> Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
>  
>  
> The static link is an extra parameter.
> And, as such, also an extra local variable.
> You only need one.
> Each nesting level would follow another chain.
> Or you can pass each nesting level as an extra parameter.
> Or you can optimize and pass locals/parameters separately.
> But there is an obvious straightforward non-optimized form. ?
>  
>  
> Here, I worked it through:
>  
>  
>  
> Why doesn't it just look something like this:
>  
>  
> nested:
>  
> void F1(int a, int b)
> {
>   int c = a + b;
>  
>   int f2()
>   {
>     int d = a + b;
>  
>     int f3()
>     {
>        return d + a + c;
>     }
>  
>     return a + c + f3();
>   }
>  
>   return f2();
> }
>  
> not nested:
>  
> 
> typedef struct {
>   /* locals */
>   int d;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
>   f1_frame_t* f1;
> } f2_frame_t;
>  
> 
> typedef struct {
>   /* locals */
>   int c;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
>   int a;
>   int b;
> } f1_frame_t;
>  
>  
> int f3(f2_frame_t* f2)
> {
>     return f2->d + f2->f1->a + f2->f1->c;
> }
>  
> 
> int f2(f1_frame_t* f1)
> {
>   int d = f1->a + f1->b;
>   return f1->a + f1->c + f3((f2_frame_t*)&d);
> }
>  
> 
> int F1(int a, int b)
> {
>   int c = a + b;
>   return f2((f1_frame_t*)&c);
> }
> 
>  
> or, alernatively, almost the same, pass each chain as another parameter:
>  
> 
> typedef struct {
>   /* locals */
>   int d;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
> } f2_frame_t;
>  
> 
> typedef struct {
>   /* locals */
>   int c;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
>   int a;
>   int b;
> } f1_frame_t;
>  
>  
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>     return f2->d + f1->a + f1->c;
> }
>  
>  
> 
> int f2(f1_frame_t* f1)
> {
>   int d = f1->a + f1->b;
>   return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
> }
>  
> 
> int F1(int a, int b)
> {
>   int c = a + b;
>   return f2((f1_frame_t*)&c);
> }
>  
>  
> This should be easily adapted to any function call convention/sequence.
> e.g. even if parameters are passed in registers.
>  
>  
> And for that matter, why don't we just transform it to be like this?
>   With the goal of reducing/eliminating gcc patches?
>  
>  
> Am I missing something?
>  
> 
> This form doesn't work?
>  
> 
> Isn't reasonably simple?
>  
> 
> Granted it might not be optimal. But it depends.
>   You know, you can copy in the local/parameter values, but then you have
>    to copy them out too. You can do analysis to show they aren't changed,
>    in which case no need to copy them out.
>   Similarly you can pass the parameters as separate parameters, by address
>    if they are ever changed.
> 
>  
> A portable transform couldn't depend on adjacency of locals and parameters.
> It would have to either copy the parameters into the frame_t, or their addresses.
>  
>  
> A portable form couldn't get the frame by taking the address of a "individual" local.
>  
>  
> Here is portable form:
>  
>  
> typedef struct {
>   int d;
>   f1_frame_t* f1;
> } f2_frame_t;
>  
> typedef struct {
>   int a;
>   int b;
>   int c;
> } f1_frame_t;
>  
> 
> int f3(f2_frame_t* f2)
> {
>     return f2->d + f2->f1->a + f2->f1->c;
> }
>  
> int f2(f1_frame_t* f1)
> {
>   f2_frame_t f;
>   f.f1 = f1;
>   f.d = f1->a + f1->b;
>   return f1->a + f1->c + f3(&f);
> }
>  
>  
> int F1(int a, int b)
> {
>   f1_frame_t f;
>   f.a = a;
>   f.b = b;
>   f.c = a + b;
>   return f2(&f);
> }
>  
>  
> or:
>  
>  
> typedef struct {
>   int d;
> } f2_frame_t;
>  
>  
> typedef struct {
>   int a;
>   int b;
>   int c;
> } f1_frame_t;
>  
>  
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>     return f2->d + f1->a + f1->c;
> }
>  
>  
> int f2(f1_frame_t* f1)
> {
>   f2_frame_t f;
>   f.d = f1->a + f1->b;
>   return f1->a + f1->c + f3(&f, f1);
> }
> 
>  
> int F1(int a, int b)
> {
>   f1_frame_t f;
>   f.a = a;
>   f.b = b;
>   f.c = a + b;
>   return f2(&f);
> }
> 
>  
>  
>  
>  - Jay
> 
> 
> 
> ----------------------------------------
>> Date: Thu, 20 May 2010 12:12:00 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>> gcc even extends C with nested functions, and the support is there for that. We use it too.
>>
>> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
>> you will ever see elsewhere. There are two static links. One is used for the first step
>> in following a static chain and points to the expected place in the target frame. The other
>> is used of subsequent steps in chain-following, and points to somewhere inside the target
>> frame that is dependent on the target procedure. It's the beginning of a subrecord where
>> all the nonlocally-referenced variables are collected. The second static link is also
>> located in there. All the nonlocally-referenced variables and parameters are duplicated
>> in there too.
>>
>> I'm not sure I remembered these details exactly right. Maybe both links point to the
>> subrecord, but one is located at a traditional procedure-independent, fixed location
>> in the frame, while the second is located in the subrecord. Also, sometimes the first
>> static link value is kept in a register and never stored.
>>
>> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
>> scheme that, I believe came from interaction between nested procedures and inlining them.
>>
>> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>>
>> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
>> with the current design of emitting debug info very early. The locations and target
>> offsets of these things aren't know until later, and m3gdb really needs to know them.
>>
>>
>> Jay K wrote:
>>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>>> Don't any of the other languages need it already?
>>> Ada? Pascal? Maybe the nested C function support?
>>>
>>> - Jay
>>> 		 	   		  


From mika at async.async.caltech.edu  Sat May 22 23:53:17 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 22 May 2010 14:53:17 -0700
Subject: [M3devel] OS for CM3
Message-ID: <20100522215317.E428D1A2096@async.async.caltech.edu>

Hi Modula-3ers,

Can anyone give me some advice on what OS to install on a new PC compute
server with 16 to 24 cores and 16 to 32 GB of RAM?  The code I'm going
to be running is all written in Modula-3 with some C and Fortran thrown
in and I want to use CM3.  The odd extra thing in Java and some analysis
in R.  Currently I'm stuck with PM3 on FreeBSD/i386.

I've always liked the ease of administration (i.e., I'm an old dog and I
don't have to learn anything new) of FreeBSD, but the threading support
seems much better with Linux?  I do really want to run multi-threaded
programs across several CPUs.

I am considering Debian/amd64.  Any other recommendations, experiences?

    Mika


From dragisha at m3w.org  Sun May 23 00:32:25 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 23 May 2010 00:32:25 +0200
Subject: [M3devel] OS for CM3
In-Reply-To: <20100522215317.E428D1A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
Message-ID: <1274567545.29716.4.camel@localhost>

There is no simple nor unique answer to this. I prefer Fedora, and I've
been using RedHat since 1996... Some people prefer RHEL, or CentOS if
they like it freer. Jumped of SLS then Slackware I've been using from
1993-1995, and never looked back.

Easy to administer and maintain, most of modern distros have GUI for
every admin task.

On Sat, 2010-05-22 at 14:53 -0700, Mika Nystrom wrote:
> Hi Modula-3ers,
> 
> Can anyone give me some advice on what OS to install on a new PC compute
> server with 16 to 24 cores and 16 to 32 GB of RAM?  The code I'm going
> to be running is all written in Modula-3 with some C and Fortran thrown
> in and I want to use CM3.  The odd extra thing in Java and some analysis
> in R.  Currently I'm stuck with PM3 on FreeBSD/i386.
> 
> I've always liked the ease of administration (i.e., I'm an old dog and I
> don't have to learn anything new) of FreeBSD, but the threading support
> seems much better with Linux?  I do really want to run multi-threaded
> programs across several CPUs.
> 
> I am considering Debian/amd64.  Any other recommendations, experiences?
> 
>     Mika

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



From jay.krell at cornell.edu  Sun May 23 01:35:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 22 May 2010 23:35:52 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <1274567545.29716.4.camel@localhost>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
Message-ID: <COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl>


Modula-3 will run on almost anything. Install something we don't work on yet and give me ssh access. :)
Like get a Loongson laptop -- comes with Linux/MIPS but can also run OpenBSD and maybe others.
Or, install something we don't have yet in Hudson yet, e.g. NetBSD/amd64, and have Olaf add jobs for it.

Seriously, for Hudson purposes, NetBSD/amd64 is probably the best, followed by NetBSD/x86.
I'll set these up eventually.


Regarding Linux, I've been using Debian, because it has about the best support for multiple architectures.
? And then the same "experience" across all of them -- same installer and package management.


Gentoo would be the next or previous choice -- not clear what the ppc64 support is in Debian.
It helps that I first used wimpy Ubuntu before moving up to the supposedly manly Debian.
Gentoo I've had trouble getting to install+boot.


OpenBSD has about the best install experience imho and a certain hard to capture purity about it.
? Examples:
???? NetBSD and FreeBSD support powerpc.
???? FreeBSD's partitioner doesn't run on powerpc though.
???? NetBSD I couldn't get to install.
???? OpenBSD was easy.
?? 
???? Attempting to install Linux or NetBSD on an SGI machine apparently killed the machine.
???? I couldn't get either to install or boot. One of them might not have local console working.
???? But again OpenBSD was easy and worked.


??? My OpenBSD/sgimips CD was actually bad. But it worked enough to boot, and the
??? the install was then easy to fallback to over the network.


But they don't have kernel threads, so, while we work, we probably scale the worst here.
? Besides, user threads are an /option/ on all Posix systems, only /required/ on OpenBSD.


I think all the user interfaces are terrible though.
I am most productive by far on NT, using find-in-files countless times daily in Visual C++ 5.0.
?It is so much better than command line grep, and it beats every other IDE/editor I have tried,
?and I have tried many. Komodo Edit is so-so. MonoDevelop was promising, but it refused
?to open *.m3 files as plain text. TextWrangler on Mac is so-so, what I use for lack
?of anything good. Eclipse is confusing to install and I don't think worked well, but I forget.


Mac is distant second in productivity.
? At least I don't have to constantly flip the newlines and it has a fast fork.


Everything else I can't even edit files on. I can't copy/paste, navigate quickly (e.g. esp. using
page up/down/home/end/mouse!). NT also has a fast console with half decent most support.


My most productive pattern is editing on NT and copying files around otherwise.


As well, consider that the NT Modula-3 backend is unique and pretty darn good.
? It is fast, in-proc, and always optimizes a certain amount.
? In its only mode, it generates significantly better code than unoptimizing gcc.


?Compiling N files on NT takes one process to compile, codegen, write objs files,
and then another one or two to link.


Compiling N files on the other systems takes one process to compile, N runs
of m3cg to generate N asssembly files, N runs to run the assembler.


If you really need an *occasional* Posixy experience on NT, there is Cygwin and SFU/SUA.
Cygwin has a very slow fork and it is very noticable.
SFU/SUA has a "normally" fast fork, and it is very noticable.


FreeBSD, Solaris, NetBSD, Linux -- should all be about the same.
?(ok, Solaris/x86 support is only in head, not release).


Then there are the non-x86 ones, like HP-UX, OSF/1, Irix, AIX, VMS... :)


Also, for Hudson purposes, we need Java.
That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
Linux now has good enough Java on all architectures.
? There was a project to eliminate all the assembly code. And we have no problem
??? e.g. now on Linux/sparc and Linux/powerpc.

All the commercial systems probably suffice also.

?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: mika at async.async.caltech.edu
> Date: Sun, 23 May 2010 00:32:25 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] OS for CM3
>
> There is no simple nor unique answer to this. I prefer Fedora, and I've
> been using RedHat since 1996... Some people prefer RHEL, or CentOS if
> they like it freer. Jumped of SLS then Slackware I've been using from
> 1993-1995, and never looked back.
>
> Easy to administer and maintain, most of modern distros have GUI for
> every admin task.
>
> On Sat, 2010-05-22 at 14:53 -0700, Mika Nystrom wrote:
>> Hi Modula-3ers,
>>
>> Can anyone give me some advice on what OS to install on a new PC compute
>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
>> to be running is all written in Modula-3 with some C and Fortran thrown
>> in and I want to use CM3. The odd extra thing in Java and some analysis
>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
>>
>> I've always liked the ease of administration (i.e., I'm an old dog and I
>> don't have to learn anything new) of FreeBSD, but the threading support
>> seems much better with Linux? I do really want to run multi-threaded
>> programs across several CPUs.
>>
>> I am considering Debian/amd64. Any other recommendations, experiences?
>>
>> Mika
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Sun May 23 01:40:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 22 May 2010 23:40:46 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <1274567545.29716.4.camel@localhost>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
Message-ID: <COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>


ps: Slackware was fine back when I used it. RedHat is ok, but it at least used to take forever to do any package management compared to Ubuntu/Debian.
Suse has/had RedHat's problem, also being rpm basedi but also seemed to lead in gui/managability.


Anyway, other than Mac and NT, all my other systems are now ssh command line and impossible to do much with. :)


ps: I also like *BSD due to the reduced number of choices, and the "integrated build", where you can build a bit
more in one nice go, not just the kernel. Linux is so darn chaotic.
But I rarely take any advantage of this.
I would really like, whatever I run, to build the entire thing from source, and do it fairly easily.
?Have the whole thing be debuggable.
?Cross building support would be nice too, though lately people seem to give up and use qemu.
? Too much building stuff wants to run as it builds, like using autoconf.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org; mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] OS for CM3
> Date: Sat, 22 May 2010 23:35:52 +0000
>
>
> Modula-3 will run on almost anything. Install something we don't work on yet and give me ssh access. :)
> Like get a Loongson laptop -- comes with Linux/MIPS but can also run OpenBSD and maybe others.
> Or, install something we don't have yet in Hudson yet, e.g. NetBSD/amd64, and have Olaf add jobs for it.
>
> Seriously, for Hudson purposes, NetBSD/amd64 is probably the best, followed by NetBSD/x86.
> I'll set these up eventually.
>
>
> Regarding Linux, I've been using Debian, because it has about the best support for multiple architectures.
>   And then the same "experience" across all of them -- same installer and package management.
>
>
> Gentoo would be the next or previous choice -- not clear what the ppc64 support is in Debian.
> It helps that I first used wimpy Ubuntu before moving up to the supposedly manly Debian.
> Gentoo I've had trouble getting to install+boot.
>
>
> OpenBSD has about the best install experience imho and a certain hard to capture purity about it.
>   Examples:
>      NetBSD and FreeBSD support powerpc.
>      FreeBSD's partitioner doesn't run on powerpc though.
>      NetBSD I couldn't get to install.
>      OpenBSD was easy.
>
>      Attempting to install Linux or NetBSD on an SGI machine apparently killed the machine.
>      I couldn't get either to install or boot. One of them might not have local console working.
>      But again OpenBSD was easy and worked.
>
>
>     My OpenBSD/sgimips CD was actually bad. But it worked enough to boot, and the
>     the install was then easy to fallback to over the network.
>
>
> But they don't have kernel threads, so, while we work, we probably scale the worst here.
>   Besides, user threads are an /option/ on all Posix systems, only /required/ on OpenBSD.
>
>
> I think all the user interfaces are terrible though.
> I am most productive by far on NT, using find-in-files countless times daily in Visual C++ 5.0.
>  It is so much better than command line grep, and it beats every other IDE/editor I have tried,
>  and I have tried many. Komodo Edit is so-so. MonoDevelop was promising, but it refused
>  to open *.m3 files as plain text. TextWrangler on Mac is so-so, what I use for lack
>  of anything good. Eclipse is confusing to install and I don't think worked well, but I forget.
>
>
> Mac is distant second in productivity.
>   At least I don't have to constantly flip the newlines and it has a fast fork.
>
>
> Everything else I can't even edit files on. I can't copy/paste, navigate quickly (e.g. esp. using
> page up/down/home/end/mouse!). NT also has a fast console with half decent most support.
>
>
> My most productive pattern is editing on NT and copying files around otherwise.
>
>
> As well, consider that the NT Modula-3 backend is unique and pretty darn good.
>   It is fast, in-proc, and always optimizes a certain amount.
>   In its only mode, it generates significantly better code than unoptimizing gcc.
>
>
>  Compiling N files on NT takes one process to compile, codegen, write objs files,
> and then another one or two to link.
>
>
> Compiling N files on the other systems takes one process to compile, N runs
> of m3cg to generate N asssembly files, N runs to run the assembler.
>
>
> If you really need an *occasional* Posixy experience on NT, there is Cygwin and SFU/SUA.
> Cygwin has a very slow fork and it is very noticable.
> SFU/SUA has a "normally" fast fork, and it is very noticable.
>
>
> FreeBSD, Solaris, NetBSD, Linux -- should all be about the same.
>  (ok, Solaris/x86 support is only in head, not release).
>
>
> Then there are the non-x86 ones, like HP-UX, OSF/1, Irix, AIX, VMS... :)
>
>
> Also, for Hudson purposes, we need Java.
> That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
> Linux now has good enough Java on all architectures.
>   There was a project to eliminate all the assembly code. And we have no problem
>     e.g. now on Linux/sparc and Linux/powerpc.
>
> All the commercial systems probably suffice also.
>
>  - Jay
>
> ----------------------------------------
>> From: dragisha at m3w.org
>> To: mika at async.async.caltech.edu
>> Date: Sun, 23 May 2010 00:32:25 +0200
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] OS for CM3
>>
>> There is no simple nor unique answer to this. I prefer Fedora, and I've
>> been using RedHat since 1996... Some people prefer RHEL, or CentOS if
>> they like it freer. Jumped of SLS then Slackware I've been using from
>> 1993-1995, and never looked back.
>>
>> Easy to administer and maintain, most of modern distros have GUI for
>> every admin task.
>>
>> On Sat, 2010-05-22 at 14:53 -0700, Mika Nystrom wrote:
>>> Hi Modula-3ers,
>>>
>>> Can anyone give me some advice on what OS to install on a new PC compute
>>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
>>> to be running is all written in Modula-3 with some C and Fortran thrown
>>> in and I want to use CM3. The odd extra thing in Java and some analysis
>>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
>>>
>>> I've always liked the ease of administration (i.e., I'm an old dog and I
>>> don't have to learn anything new) of FreeBSD, but the threading support
>>> seems much better with Linux? I do really want to run multi-threaded
>>> programs across several CPUs.
>>>
>>> I am considering Debian/amd64. Any other recommendations, experiences?
>>>
>>> Mika
>>
>> --
>> Dragi?a Duri?
>>
>
 		 	   		  

From mika at async.async.caltech.edu  Sun May 23 02:08:49 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 22 May 2010 17:08:49 -0700
Subject: [M3devel] OS for CM3
In-Reply-To: <COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl> 
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
	<COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>
Message-ID: <20100523000849.BA8E61A2096@async.async.caltech.edu>

Well I know all about the various OS tradeoffs, I was asking more
about Modula-3 itself.

I want to use kernel threads, so I can share large data structures 
across CPUs.  This is for production work, not a development platform.
My main development platform will probably stay FreeBSD/i386 for a while.

Yes I agree Linux is chaotic.  But I can't stand Windows, because I
hate GUIs (because I can't automate them and my philosophy is to make
the computer work for me, not the other way around).  I know all the
old-fashioned Unix admin commands by heart (I am somewhat dismayed
that the old kill -1 convention for making daemons re-read their config
files seems to have fallen by the wayside!)  My .twmrc is dated 1992.
And PageUp etc work fine in emacs for me :-)

In other words the system will just have command-line access.  In
fact it's supposed to sit in a locked machine room.

Err, to the point... maybe it got lost in the vague generality of the
question.  

My real question is: do kernel threads work on *BSD at all?

I haven't done a proper back to back test but the Debian system
"seems faster" than FreeBSD, running on the same amd64 hardware.

Or perhaps.. crazy question.. can one make a hackintosh/amd64 out of a
16-core machine?

I seem to remember Tony made some (bad) comments about FreeBSD kernel
threads a few months ago...

    Mika

Jay K writes:
>
>ps: Slackware was fine back when I used it. RedHat is ok=2C but it at least=
> used to take forever to do any package management compared to Ubuntu/Debia=
>n.
>Suse has/had RedHat's problem=2C also being rpm basedi but also seemed to l=
>ead in gui/managability.
>
>
>Anyway=2C other than Mac and NT=2C all my other systems are now ssh command=
> line and impossible to do much with. :)
>
>
>ps: I also like *BSD due to the reduced number of choices=2C and the "integ=
>rated build"=2C where you can build a bit
>more in one nice go=2C not just the kernel. Linux is so darn chaotic.
>But I rarely take any advantage of this.
>I would really like=2C whatever I run=2C to build the entire thing from sou=
>rce=2C and do it fairly easily.
>=A0Have the whole thing be debuggable.
>=A0Cross building support would be nice too=2C though lately people seem to=
> give up and use qemu.
>=A0 Too much building stuff wants to run as it builds=2C like using autocon=
>f.
>
>
>=A0- Jay
>
>----------------------------------------
>> From: jay.krell at cornell.edu
>> To: dragisha at m3w.org=3B mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] OS for CM3
>> Date: Sat=2C 22 May 2010 23:35:52 +0000
>>
>>
>> Modula-3 will run on almost anything. Install something we don't work on =
>yet and give me ssh access. :)
>> Like get a Loongson laptop -- comes with Linux/MIPS but can also run Open=
>BSD and maybe others.
>> Or=2C install something we don't have yet in Hudson yet=2C e.g. NetBSD/am=
>d64=2C and have Olaf add jobs for it.
>>
>> Seriously=2C for Hudson purposes=2C NetBSD/amd64 is probably the best=2C =
>followed by NetBSD/x86.
>> I'll set these up eventually.
>>
>>
>> Regarding Linux=2C I've been using Debian=2C because it has about the bes=
>t support for multiple architectures.
>>   And then the same "experience" across all of them -- same installer and=
> package management.
>>
>>
>> Gentoo would be the next or previous choice -- not clear what the ppc64 s=
>upport is in Debian.
>> It helps that I first used wimpy Ubuntu before moving up to the supposedl=
>y manly Debian.
>> Gentoo I've had trouble getting to install+boot.
>>
>>
>> OpenBSD has about the best install experience imho and a certain hard to =
>capture purity about it.
>>   Examples:
>>      NetBSD and FreeBSD support powerpc.
>>      FreeBSD's partitioner doesn't run on powerpc though.
>>      NetBSD I couldn't get to install.
>>      OpenBSD was easy.
>>
>>      Attempting to install Linux or NetBSD on an SGI machine apparently k=
>illed the machine.
>>      I couldn't get either to install or boot. One of them might not have=
> local console working.
>>      But again OpenBSD was easy and worked.
>>
>>
>>     My OpenBSD/sgimips CD was actually bad. But it worked enough to boot=
>=2C and the
>>     the install was then easy to fallback to over the network.
>>
>>
>> But they don't have kernel threads=2C so=2C while we work=2C we probably =
>scale the worst here.
>>   Besides=2C user threads are an /option/ on all Posix systems=2C only /r=
>equired/ on OpenBSD.
>>
>>
>> I think all the user interfaces are terrible though.
>> I am most productive by far on NT=2C using find-in-files countless times =
>daily in Visual C++ 5.0.
>>  It is so much better than command line grep=2C and it beats every other =
>IDE/editor I have tried=2C
>>  and I have tried many. Komodo Edit is so-so. MonoDevelop was promising=
>=2C but it refused
>>  to open *.m3 files as plain text. TextWrangler on Mac is so-so=2C what I=
> use for lack
>>  of anything good. Eclipse is confusing to install and I don't think work=
>ed well=2C but I forget.
>>
>>
>> Mac is distant second in productivity.
>>   At least I don't have to constantly flip the newlines and it has a fast=
> fork.
>>
>>
>> Everything else I can't even edit files on. I can't copy/paste=2C navigat=
>e quickly (e.g. esp. using
>> page up/down/home/end/mouse!). NT also has a fast console with half decen=
>t most support.
>>
>>
>> My most productive pattern is editing on NT and copying files around othe=
>rwise.
>>
>>
>> As well=2C consider that the NT Modula-3 backend is unique and pretty dar=
>n good.
>>   It is fast=2C in-proc=2C and always optimizes a certain amount.
>>   In its only mode=2C it generates significantly better code than unoptim=
>izing gcc.
>>
>>
>>  Compiling N files on NT takes one process to compile=2C codegen=2C write=
> objs files=2C
>> and then another one or two to link.
>>
>>
>> Compiling N files on the other systems takes one process to compile=2C N =
>runs
>> of m3cg to generate N asssembly files=2C N runs to run the assembler.
>>
>>
>> If you really need an *occasional* Posixy experience on NT=2C there is Cy=
>gwin and SFU/SUA.
>> Cygwin has a very slow fork and it is very noticable.
>> SFU/SUA has a "normally" fast fork=2C and it is very noticable.
>>
>>
>> FreeBSD=2C Solaris=2C NetBSD=2C Linux -- should all be about the same.
>>  (ok=2C Solaris/x86 support is only in head=2C not release).
>>
>>
>> Then there are the non-x86 ones=2C like HP-UX=2C OSF/1=2C Irix=2C AIX=2C =
>VMS... :)
>>
>>
>> Also=2C for Hudson purposes=2C we need Java.
>> That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
>> Linux now has good enough Java on all architectures.
>>   There was a project to eliminate all the assembly code. And we have no =
>problem
>>     e.g. now on Linux/sparc and Linux/powerpc.
>>
>> All the commercial systems probably suffice also.
>>
>>  - Jay
>>
>> ----------------------------------------
>>> From: dragisha at m3w.org
>>> To: mika at async.async.caltech.edu
>>> Date: Sun=2C 23 May 2010 00:32:25 +0200
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] OS for CM3
>>>
>>> There is no simple nor unique answer to this. I prefer Fedora=2C and I'v=
>e
>>> been using RedHat since 1996... Some people prefer RHEL=2C or CentOS if
>>> they like it freer. Jumped of SLS then Slackware I've been using from
>>> 1993-1995=2C and never looked back.
>>>
>>> Easy to administer and maintain=2C most of modern distros have GUI for
>>> every admin task.
>>>
>>> On Sat=2C 2010-05-22 at 14:53 -0700=2C Mika Nystrom wrote:
>>>> Hi Modula-3ers=2C
>>>>
>>>> Can anyone give me some advice on what OS to install on a new PC comput=
>e
>>>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
>>>> to be running is all written in Modula-3 with some C and Fortran thrown
>>>> in and I want to use CM3. The odd extra thing in Java and some analysis
>>>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
>>>>
>>>> I've always liked the ease of administration (i.e.=2C I'm an old dog an=
>d I
>>>> don't have to learn anything new) of FreeBSD=2C but the threading suppo=
>rt
>>>> seems much better with Linux? I do really want to run multi-threaded
>>>> programs across several CPUs.
>>>>
>>>> I am considering Debian/amd64. Any other recommendations=2C experiences=
>?
>>>>
>>>> Mika
>>>
>>> --
>>> Dragi=B9a Duri=E6
>>>
>>
> 		 	   		  =


From mika at async.async.caltech.edu  Sun May 23 02:13:49 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 22 May 2010 17:13:49 -0700
Subject: [M3devel] OS for CM3
In-Reply-To: <COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl> 
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
	<COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl>
Message-ID: <20100523001349.DCCE81A2096@async.async.caltech.edu>

Jay K writes:
>
>Modula-3 will run on almost anything. Install something we don't work on ye=
>t and give me ssh access. :)

Speaking of which, how's ALPHAOSF1 doing?  I'm trying to get a project
started that might involve Alphas...

   Mika


From jay.krell at cornell.edu  Sun May 23 03:06:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 23 May 2010 01:06:22 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <20100523001349.DCCE81A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>, ,
	<1274567545.29716.4.camel@localhost>,
	<COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl>,
	<20100523001349.DCCE81A2096@async.async.caltech.edu>
Message-ID: <COL101-W109BCFDBACAB678FB55CDAE6E60@phx.gbl>

I haven't set up any of my Alphas yet. Ssh access to yours? :)

 - Jay

> To: jay.krell at cornell.edu
> Date: Sat, 22 May 2010 17:13:49 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] OS for CM3
> 
> Jay K writes:
> >
> >Modula-3 will run on almost anything. Install something we don't work on ye=
> >t and give me ssh access. :)
> 
> Speaking of which, how's ALPHAOSF1 doing?  I'm trying to get a project
> started that might involve Alphas...
> 
>    Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100523/740d91b1/attachment.html>

From jay.krell at cornell.edu  Sun May 23 03:49:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 23 May 2010 01:49:07 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <20100523000849.BA8E61A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
	<COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>,
	<20100523000849.BA8E61A2096@async.async.caltech.edu>
Message-ID: <COL101-W1561F238322CDB78B1CE53E6E60@phx.gbl>

FreeBSD is ok, NetBSD prob ok, not tested as much. OpenBSD not good.

 - Jay

> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] OS for CM3 
> Date: Sat, 22 May 2010 17:08:49 -0700
> From: mika at async.async.caltech.edu
> 
> Well I know all about the various OS tradeoffs, I was asking more
> about Modula-3 itself.
> 
> I want to use kernel threads, so I can share large data structures 
> across CPUs.  This is for production work, not a development platform.
> My main development platform will probably stay FreeBSD/i386 for a while.
> 
> Yes I agree Linux is chaotic.  But I can't stand Windows, because I
> hate GUIs (because I can't automate them and my philosophy is to make
> the computer work for me, not the other way around).  I know all the
> old-fashioned Unix admin commands by heart (I am somewhat dismayed
> that the old kill -1 convention for making daemons re-read their config
> files seems to have fallen by the wayside!)  My .twmrc is dated 1992.
> And PageUp etc work fine in emacs for me :-)
> 
> In other words the system will just have command-line access.  In
> fact it's supposed to sit in a locked machine room.
> 
> Err, to the point... maybe it got lost in the vague generality of the
> question.  
> 
> My real question is: do kernel threads work on *BSD at all?
> 
> I haven't done a proper back to back test but the Debian system
> "seems faster" than FreeBSD, running on the same amd64 hardware.
> 
> Or perhaps.. crazy question.. can one make a hackintosh/amd64 out of a
> 16-core machine?
> 
> I seem to remember Tony made some (bad) comments about FreeBSD kernel
> threads a few months ago...
> 
>     Mika
> 
> Jay K writes:
> >
> >ps: Slackware was fine back when I used it. RedHat is ok=2C but it at least=
> > used to take forever to do any package management compared to Ubuntu/Debia=
> >n.
> >Suse has/had RedHat's problem=2C also being rpm basedi but also seemed to l=
> >ead in gui/managability.
> >
> >
> >Anyway=2C other than Mac and NT=2C all my other systems are now ssh command=
> > line and impossible to do much with. :)
> >
> >
> >ps: I also like *BSD due to the reduced number of choices=2C and the "integ=
> >rated build"=2C where you can build a bit
> >more in one nice go=2C not just the kernel. Linux is so darn chaotic.
> >But I rarely take any advantage of this.
> >I would really like=2C whatever I run=2C to build the entire thing from sou=
> >rce=2C and do it fairly easily.
> >=A0Have the whole thing be debuggable.
> >=A0Cross building support would be nice too=2C though lately people seem to=
> > give up and use qemu.
> >=A0 Too much building stuff wants to run as it builds=2C like using autocon=
> >f.
> >
> >
> >=A0- Jay
> >
> >----------------------------------------
> >> From: jay.krell at cornell.edu
> >> To: dragisha at m3w.org=3B mika at async.async.caltech.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: RE: [M3devel] OS for CM3
> >> Date: Sat=2C 22 May 2010 23:35:52 +0000
> >>
> >>
> >> Modula-3 will run on almost anything. Install something we don't work on =
> >yet and give me ssh access. :)
> >> Like get a Loongson laptop -- comes with Linux/MIPS but can also run Open=
> >BSD and maybe others.
> >> Or=2C install something we don't have yet in Hudson yet=2C e.g. NetBSD/am=
> >d64=2C and have Olaf add jobs for it.
> >>
> >> Seriously=2C for Hudson purposes=2C NetBSD/amd64 is probably the best=2C =
> >followed by NetBSD/x86.
> >> I'll set these up eventually.
> >>
> >>
> >> Regarding Linux=2C I've been using Debian=2C because it has about the bes=
> >t support for multiple architectures.
> >>   And then the same "experience" across all of them -- same installer and=
> > package management.
> >>
> >>
> >> Gentoo would be the next or previous choice -- not clear what the ppc64 s=
> >upport is in Debian.
> >> It helps that I first used wimpy Ubuntu before moving up to the supposedl=
> >y manly Debian.
> >> Gentoo I've had trouble getting to install+boot.
> >>
> >>
> >> OpenBSD has about the best install experience imho and a certain hard to =
> >capture purity about it.
> >>   Examples:
> >>      NetBSD and FreeBSD support powerpc.
> >>      FreeBSD's partitioner doesn't run on powerpc though.
> >>      NetBSD I couldn't get to install.
> >>      OpenBSD was easy.
> >>
> >>      Attempting to install Linux or NetBSD on an SGI machine apparently k=
> >illed the machine.
> >>      I couldn't get either to install or boot. One of them might not have=
> > local console working.
> >>      But again OpenBSD was easy and worked.
> >>
> >>
> >>     My OpenBSD/sgimips CD was actually bad. But it worked enough to boot=
> >=2C and the
> >>     the install was then easy to fallback to over the network.
> >>
> >>
> >> But they don't have kernel threads=2C so=2C while we work=2C we probably =
> >scale the worst here.
> >>   Besides=2C user threads are an /option/ on all Posix systems=2C only /r=
> >equired/ on OpenBSD.
> >>
> >>
> >> I think all the user interfaces are terrible though.
> >> I am most productive by far on NT=2C using find-in-files countless times =
> >daily in Visual C++ 5.0.
> >>  It is so much better than command line grep=2C and it beats every other =
> >IDE/editor I have tried=2C
> >>  and I have tried many. Komodo Edit is so-so. MonoDevelop was promising=
> >=2C but it refused
> >>  to open *.m3 files as plain text. TextWrangler on Mac is so-so=2C what I=
> > use for lack
> >>  of anything good. Eclipse is confusing to install and I don't think work=
> >ed well=2C but I forget.
> >>
> >>
> >> Mac is distant second in productivity.
> >>   At least I don't have to constantly flip the newlines and it has a fast=
> > fork.
> >>
> >>
> >> Everything else I can't even edit files on. I can't copy/paste=2C navigat=
> >e quickly (e.g. esp. using
> >> page up/down/home/end/mouse!). NT also has a fast console with half decen=
> >t most support.
> >>
> >>
> >> My most productive pattern is editing on NT and copying files around othe=
> >rwise.
> >>
> >>
> >> As well=2C consider that the NT Modula-3 backend is unique and pretty dar=
> >n good.
> >>   It is fast=2C in-proc=2C and always optimizes a certain amount.
> >>   In its only mode=2C it generates significantly better code than unoptim=
> >izing gcc.
> >>
> >>
> >>  Compiling N files on NT takes one process to compile=2C codegen=2C write=
> > objs files=2C
> >> and then another one or two to link.
> >>
> >>
> >> Compiling N files on the other systems takes one process to compile=2C N =
> >runs
> >> of m3cg to generate N asssembly files=2C N runs to run the assembler.
> >>
> >>
> >> If you really need an *occasional* Posixy experience on NT=2C there is Cy=
> >gwin and SFU/SUA.
> >> Cygwin has a very slow fork and it is very noticable.
> >> SFU/SUA has a "normally" fast fork=2C and it is very noticable.
> >>
> >>
> >> FreeBSD=2C Solaris=2C NetBSD=2C Linux -- should all be about the same.
> >>  (ok=2C Solaris/x86 support is only in head=2C not release).
> >>
> >>
> >> Then there are the non-x86 ones=2C like HP-UX=2C OSF/1=2C Irix=2C AIX=2C =
> >VMS... :)
> >>
> >>
> >> Also=2C for Hudson purposes=2C we need Java.
> >> That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
> >> Linux now has good enough Java on all architectures.
> >>   There was a project to eliminate all the assembly code. And we have no =
> >problem
> >>     e.g. now on Linux/sparc and Linux/powerpc.
> >>
> >> All the commercial systems probably suffice also.
> >>
> >>  - Jay
> >>
> >> ----------------------------------------
> >>> From: dragisha at m3w.org
> >>> To: mika at async.async.caltech.edu
> >>> Date: Sun=2C 23 May 2010 00:32:25 +0200
> >>> CC: m3devel at elegosoft.com
> >>> Subject: Re: [M3devel] OS for CM3
> >>>
> >>> There is no simple nor unique answer to this. I prefer Fedora=2C and I'v=
> >e
> >>> been using RedHat since 1996... Some people prefer RHEL=2C or CentOS if
> >>> they like it freer. Jumped of SLS then Slackware I've been using from
> >>> 1993-1995=2C and never looked back.
> >>>
> >>> Easy to administer and maintain=2C most of modern distros have GUI for
> >>> every admin task.
> >>>
> >>> On Sat=2C 2010-05-22 at 14:53 -0700=2C Mika Nystrom wrote:
> >>>> Hi Modula-3ers=2C
> >>>>
> >>>> Can anyone give me some advice on what OS to install on a new PC comput=
> >e
> >>>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
> >>>> to be running is all written in Modula-3 with some C and Fortran thrown
> >>>> in and I want to use CM3. The odd extra thing in Java and some analysis
> >>>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
> >>>>
> >>>> I've always liked the ease of administration (i.e.=2C I'm an old dog an=
> >d I
> >>>> don't have to learn anything new) of FreeBSD=2C but the threading suppo=
> >rt
> >>>> seems much better with Linux? I do really want to run multi-threaded
> >>>> programs across several CPUs.
> >>>>
> >>>> I am considering Debian/amd64. Any other recommendations=2C experiences=
> >?
> >>>>
> >>>> Mika
> >>>
> >>> --
> >>> Dragi=B9a Duri=E6
> >>>
> >>
> > 		 	   		  =
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100523/c9ebf99a/attachment.html>

From dragisha at m3w.org  Sun May 23 04:14:25 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 23 May 2010 04:14:25 +0200
Subject: [M3devel] ***SPAM*** RE:  OS for CM3
In-Reply-To: <COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
	,<1274567545.29716.4.camel@localhost>
	<COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>
Message-ID: <1274580865.29716.6.camel@localhost>

And of course .deb is superior to .rpm.. Ok, you win! :)

RedHat package management compared do Fedora's yum is Stone Age. Also -
yum supports multiarch nicely, as does rpm it's based on.

On Sat, 2010-05-22 at 23:40 +0000, Jay K wrote:
> 
> ps: Slackware was fine back when I used it. RedHat is ok, but it at
> least used to take forever to do any package management compared to
> Ubuntu/Debian.
> Suse has/had RedHat's problem, also being rpm basedi but also seemed
> to lead in gui/managability.
> 
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From dabenavidesd at yahoo.es  Tue May 25 06:07:24 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 25 May 2010 04:07:24 +0000 (GMT)
Subject: [M3devel] OS for CM3
In-Reply-To: <20100522215317.E428D1A2096@async.async.caltech.edu>
Message-ID: <729398.10895.qm@web23605.mail.ird.yahoo.com>

Hi:
if easy of administration is what you are looking for maybe a bsd flavour a is the right choice of use probably it would be a linux distro but a common sense of easy administration and use like ubuntu rh/centos server or why not a gentoo or archlinux if customization is what you want to add more cores linux will support up to 1024 and the small or medium size servers are commonly used in this servers sizes I guess you have a good choice to take advantage, how many does support Win server 2k3 (up to 64?) an another bsd up to how many?  

Hope it helps, thanks in advance

--- El s?b, 22/5/10, Mika Nystrom <mika at async.async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.async.caltech.edu>
> Asunto: [M3devel] OS for CM3
> Para: m3devel at elegosoft.com
> Fecha: s?bado, 22 de mayo, 2010 16:53
> Hi Modula-3ers,
> 
> Can anyone give me some advice on what OS to install on a
> new PC compute
> server with 16 to 24 cores and 16 to 32 GB of RAM? 
> The code I'm going
> to be running is all written in Modula-3 with some C and
> Fortran thrown
> in and I want to use CM3.  The odd extra thing in Java
> and some analysis
> in R.  Currently I'm stuck with PM3 on FreeBSD/i386.
> 
> I've always liked the ease of administration (i.e., I'm an
> old dog and I
> don't have to learn anything new) of FreeBSD, but the
> threading support
> seems much better with Linux?  I do really want to run
> multi-threaded
> programs across several CPUs.
> 
> I am considering Debian/amd64.  Any other
> recommendations, experiences?
> 
>     Mika
> 


      


From jay.krell at cornell.edu  Wed May 26 07:58:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 05:58:54 +0000
Subject: [M3devel] separate directory for gcc-4.5? import binutils?
Message-ID: <COL101-W500D7CADC89644958BFA09E6E90@phx.gbl>


Anyone object if I create gcc-4.5.0 or gcc-4.5 next to m3cc/gcc?
Anyone object if I import binutils?

Both are tenuous but possibly useful.


Importing gcc-4.5.0 allows for an easier/slower move to it, with somewhat easier to read history.

?- m3cc/src/m3makefile could chose between gcc and gcc-4.5.0. 
?? As they are tested they could move to gcc-4.5.0.

?- The original import wouldn't have the Modula-3 diffs.
?? It might be possible to have CVS do the future merges.
?? At least maybe to 4.5.1, 4.5.2, etc.
?? Which is a reason to call it 4.5.

?- But it does add considerably to the source tree size and time to cvs checkout/upd.

?- We'd probably want to symlink gmp/mpfr, and now mpc.
?? Really those should probably be *not* under gcc, but outside,
?? build them first, point gcc at them the "same" way it would.
?? Point being
???? - more granular "clean"
???? - split up the tree in terms of history/import/sharing 


Importing binutils might kinda/sorta allow better cross support.
gcc+binutils are 2 out of 3 pieces need to build every complete cross tools.
The third piece is headers/libraries for each system.


One can at least assemble the assembly to object files.


Or not. I can also merge our changes into 4.5.0, test a few but not all targets, and go.
e.g. Darwin/amd64, Linux/x86, Solaris/sparc32.
?

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Wed May 26 08:05:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 06:05:25 +0000
Subject: [M3devel] m3cc static chain stuff
Message-ID: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>


Can any of this be removed?
Can we really not just use "unfold-nested-procs" like NT386?
We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
generally a considered the responsibility of optimizers.

Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
Maybe I'll try without.


diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
--- /src/orig/gcc-4.3.0/gcc/tree-nested.c??? 2008-02-15 09:36:43.000000000 -0800
+++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c??? 2010-05-09 22:27:58.000000000 -0700


-/* Build or return the RECORD_TYPE that describes the frame state that is
-?? shared between INFO->CONTEXT and its nested functions.? This record will
-?? not be complete until finalize_nesting_tree; up until that point we'll
+/* This must agree with the string defined by the same name in m3gdb, file
+?? m3-util.c */ 
+static const char * nonlocal_var_rec_name = "_nonlocal_var_rec"; 
+
+/* Build or return the RECORD_TYPE that describes the non-local frame struct 
+?? that is shared between INFO->CONTEXT and its nested functions.? This record 
+?? will not be complete until finalize_nesting_tree; up until that point we'll
??? be adding fields as necessary.
?
??? We also build the DECL that represents this frame in the function.? */
@@ -209,7 +224,8 @@
?????? free (name);
?
?????? info->frame_type = type;
-????? info->frame_decl = create_tmp_var_for (info, type, "FRAME");
+????? info->frame_decl 
+??????? = create_tmp_var_for (info, type, nonlocal_var_rec_name);
?
?????? /* ??? Always make it addressable for now, since it is meant to
???? ?be pointed to by the static chain pointer.? This pessimizes
@@ -218,6 +234,8 @@
???? ?reachable, but the true pessimization is to create the non-
???? ?local frame structure in the first place.? */
?????? TREE_ADDRESSABLE (info->frame_decl) = 1;
+????? /* m3gdb needs to know about this variable. */ 
+????? DECL_IGNORED_P (info->frame_decl) = 0;? 
???? }
?? return type;
?}
@@ -290,6 +308,10 @@
?? return *slot;
?}
?
+/* This must agree with the string defined by the same name in m3gdb, file
+?? m3_util.c */ 
+static const char * static_link_var_name = "_static_link_var"; 
+
?/* Build or return the variable that holds the static chain within
??? INFO->CONTEXT.? This variable may only be used within INFO->CONTEXT.? */
?
@@ -310,9 +332,14 @@
???? ?Note also that it's represented as a parameter.? This is more
???? ?close to the truth, since the initial value does come from 
???? ?the caller.? */
-????? decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
+????? decl = build_decl 
+?????????????? (PARM_DECL, get_identifier (static_link_var_name), type);
+????? TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */ 
?????? DECL_ARTIFICIAL (decl) = 1;
-????? DECL_IGNORED_P (decl) = 1;
+
+????? /* m3gdb needs to know about this variable. */ 
+????? DECL_IGNORED_P (decl) = 0;
+
?????? TREE_USED (decl) = 1;
?????? DECL_CONTEXT (decl) = info->context;
?????? DECL_ARG_TYPE (decl) = type;
@@ -326,7 +353,11 @@
?? return decl;
?}
?
-/* Build or return the field within the non-local frame state that holds
+/* This must agree with the string defined by the same name in m3gdb, file
+?? m3_util.c */ 
+static const char * static_link_copy_field_name = "_static_link_copy_field"; 
+
+/* Build or return the field within the non-local frame struct that holds
??? the static chain for INFO->CONTEXT.? This is the way to walk back up
??? multiple nesting levels.? */
?
@@ -339,10 +370,12 @@
?????? tree type = build_pointer_type (get_frame_type (info->outer));
?
?????? field = make_node (FIELD_DECL);
-????? DECL_NAME (field) = get_identifier ("__chain");
+????? DECL_NAME (field) = get_identifier (static_link_copy_field_name);
?????? TREE_TYPE (field) = type;
?????? DECL_ALIGN (field) = TYPE_ALIGN (type);
?????? DECL_NONADDRESSABLE_P (field) = 1;
+????? /* m3gdb should know about this field. */ 
+????? DECL_IGNORED_P (field) = 0;? 
?
?????? insert_field_into_struct (get_frame_type (info), field);
?
@@ -465,7 +498,7 @@
?? return *slot;
?} 
?
-/* Build or return the field within the non-local frame state that holds
+/* Build or return the field within the non-local frame struct that holds
??? the non-local goto "jmp_buf".? The buffer itself is maintained by the
??? rtl middle-end as dynamic stack space is allocated.? */
?
@@ -1620,6 +1653,9 @@
?? switch (TREE_CODE (t))
???? {
???? case ADDR_EXPR:
+????? if (TREE_STATIC (t))
+??? break;
+
?????? /* Build
???? ?? T.1 = &CHAIN->tramp;
???? ?? T.2 = __builtin_adjust_trampoline (T.1);
@@ -1714,6 +1750,22 @@
???? }
?????? break;
?
+??? case STATIC_CHAIN_EXPR:
+????? decl = TREE_OPERAND (t, 0);
+????? target_context = decl_function_context (decl);
+????? if (target_context)
+??? {
+??? ? if (info->context == target_context)
+??? ??? {
+??? ????? /* Make sure frame_decl gets created.? */
+??? ????? (void) get_frame_type (info);
+??? ??? }
+??? ? *tp = get_static_chain (info, target_context, &wi->tsi);
+??? }
+????? else
+??? *tp = null_pointer_node;
+????? break;
+
???? case RETURN_EXPR:
???? case GIMPLE_MODIFY_STMT:
???? case WITH_SIZE_EXPR:
@@ -1768,13 +1820,22 @@
?? return NULL_TREE;
?}
?
+static bool
+debug_static_links (void) 
+{ return
+??? write_symbols != NO_DEBUG
+??? && debug_info_level != DINFO_LEVEL_NONE
+??? && debug_info_level != DINFO_LEVEL_TERSE;
+
+} /* debug_static_links */ 
+
?/* Walk the nesting tree starting with ROOT, depth first.? Convert all
??? trampolines and call expressions.? On the way back up, determine if
??? a nested function actually uses its static chain; if not, remember that.? */
?
?static void
?convert_all_function_calls (struct nesting_info *root)
-{
+{ 
?? do
???? {
?????? if (root->inner)
@@ -1784,7 +1845,10 @@
?????? walk_function (convert_call_expr, root);
?
?????? /* If the function does not use a static chain, then remember that.? */
-????? if (root->outer && !root->chain_decl && !root->chain_field)
+????? if (root->outer && !root->chain_decl && !root->chain_field
+/* REMOVE ME: */ 
+????????? /* && !debug_static_links () */ 
+???????? )
???? DECL_NO_STATIC_CHAIN (root->context) = 1;
?????? else
???? gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
@@ -1806,6 +1870,21 @@
?? tree context = root->context;
?? struct function *sf;
?
+/* REMOVEME: */ 
+? /* If this is a nested function and we are supporting debugging via
+???? m3gdb, we always need a chain_decl, so m3gdb can find the static 
+???? chain, even if the programmer's code doesn't use it. */ 
+? if (false && root->outer && debug_static_links () )
+??? { tree static_chain_decl, temp, stmt;
+????? /* This is a desperate attempt to get later code generation to 
+???????? store the static link.? If it works, it'll be a miracle. */ 
+????? static_chain_decl = get_chain_decl (root); 
+????? stmt = build_addr (static_chain_decl, root->context); 
+????? temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
+????? stmt = build_gimple_modify_stmt (temp, static_chain_decl);
+????? append_to_statement_list (stmt, &stmt_list);
+??? } 
+
?? /* If we created a non-local frame type or decl, we need to lay them
????? out at this time.? */
?? if (root->frame_type)
@@ -1912,7 +1991,7 @@
????? proper BIND_EXPR.? */
?? if (root->new_local_var_chain)
???? declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
-??? ??? ? false);
+??? ??? ? true);
?? if (root->debug_var_chain)
???? declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
???? ??? ? true);


 		 	   		  

From jay.krell at cornell.edu  Wed May 26 09:50:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 07:50:40 +0000
Subject: [M3devel] newer versions might obviate some of our changes
Message-ID: <COL101-W329B816AD3C1C3C5DBD3DE6E90@phx.gbl>


I haven't tracked down everything, but in a few cases, I notice that functions we modified
are removed. It appears we might have been fixing bugs that got fixed by gcc later.

Here is an example:

We changed mark_non_addressable in tree-ssa-alias.c.

First it changed to something else:

2008-06-04? Richard Guenther? <rguenther at suse.de>

??? * tree-flow-inline.h (is_global_var): Do not check TREE_STATIC on MTAGs.
??? (is_call_clobbered): Always check var_ann->call_clobbered.
??? (mark_call_clobbered): Always set var_ann->call_clobbered.
??? (clear_call_clobbered): Always clear var_ann->call_clobbered.
??? * tree-ssa-alias.c (mark_non_addressable): Use clear_call_clobbered.


then that something else got removed:


2009-04-03? Richard Guenther? <rguenther at suse.de>

??? PR middle-end/13146
??? PR tree-optimization/23940
... many ..
??? * tree-flow-inline.h (gimple_aliases_computed_p,
??? gimple_addressable_vars, gimple_call_clobbered_vars,
??? gimple_call_used_vars, gimple_global_var, may_aliases, memory_partition,
??? factoring_name_p, mark_call_clobbered, clear_call_clobbered,
??? compare_ssa_operands_equal, symbol_mem_tag, set_symbol_mem_tag,
??? gimple_mem_ref_stats): Remove.


In tree-cfg.c, we modified remove_useless_stmts_bind:

????? /* Removing the BIND_EXPR will break Modula-3 debug information by? 
???????? making explicitly programmed blocks disappear. */ 
????? && ( write_symbols == NO_DEBUG
?????????? || debug_info_level == DINFO_LEVEL_NONE
?????????? || debug_info_level == DINFO_LEVEL_TERSE ))


the change seems dubious to me -- generating symbols should NOT change codegen.

Anyway, this function and a lot around it is gone now:


2009-10-08? Michael Matz? <matz at suse.de>

??? PR middle-end/41573
...
??? * tree-cfg.c (struct rus_data, remove_useless_stmts_warn_notreached,
??? remove_useless_stmts_cond, remove_useless_stmts_tf,
??? remove_useless_stmts_tc, remove_useless_stmts_bind,
??? remove_useless_stmts_goto, remove_useless_stmts_label,
??? remove_useless_stmts_1, remove_useless_stmts,
??? pass_remove_useless_stmts): Remove.


also, some of the OpenBSD patches got applied, at least x86 and sparc64.
Not clear about powerpc and amd64. (maybe amd64 is x86 -m64? powerpc
definitely seems to be missing).


I should look more closely, see if they were fixing something similar to what we were
and make sure they didn't just move the problem elsewhere.


Later,
?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 09:55:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 07:55:19 +0000
Subject: [M3devel] m3cc static chain stuff
Message-ID: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>


I'm going to try to keep the code that seems to do anything, however:

1) if (false && 

?I plan to remove that.


2)
+????? if (root->outer && !root->chain_decl && !root->chain_field
+/* REMOVE ME: */ 
+????????? /* && !debug_static_links () */ 
+???????? )


I can't find where that would apply, and it is commented out anyway so I'll remove it.


I'm open to arguments though. :)

dbxout.c
+#if 0
+/* Code copied from 1.4.2.2: */ 


I can cheaply enough keep that...should we really though?


I really think we can reduce our changes.
Enough type information should be passed around so that regular gdb works. Imho.
?And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
? don't cause internal compiler errors. So that debug info might be generated on systems
? that don't support stabs though granted they are few and minor (hppa64-hpux).
Nested functions should be transformed to not be nested. Imho.
Optimization should be allowed to inhibit debugging as much as it does for any other language.


I realize the type information getting around is probably a lot of work.
And it is needed in m3back also, and probably not shared work.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: m3cc static chain stuff
> Date: Wed, 26 May 2010 06:05:25 +0000
>
>
> Can any of this be removed?
> Can we really not just use "unfold-nested-procs" like NT386?
> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
> generally a considered the responsibility of optimizers.
>
> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
> Maybe I'll try without.
>
>
> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
>
>
> -/* Build or return the RECORD_TYPE that describes the frame state that is
> -   shared between INFO->CONTEXT and its nested functions.  This record will
> -   not be complete until finalize_nesting_tree; up until that point we'll
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3-util.c */
> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
> +
> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
> +   that is shared between INFO->CONTEXT and its nested functions.  This record
> +   will not be complete until finalize_nesting_tree; up until that point we'll
>     be adding fields as necessary.
>
>     We also build the DECL that represents this frame in the function.  */
> @@ -209,7 +224,8 @@
>        free (name);
>
>        info->frame_type = type;
> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
> +      info->frame_decl
> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>
>        /* ??? Always make it addressable for now, since it is meant to
>       be pointed to by the static chain pointer.  This pessimizes
> @@ -218,6 +234,8 @@
>       reachable, but the true pessimization is to create the non-
>       local frame structure in the first place.  */
>        TREE_ADDRESSABLE (info->frame_decl) = 1;
> +      /* m3gdb needs to know about this variable. */
> +      DECL_IGNORED_P (info->frame_decl) = 0;
>      }
>    return type;
>  }
> @@ -290,6 +308,10 @@
>    return *slot;
>  }
>
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */
> +static const char * static_link_var_name = "_static_link_var";
> +
>  /* Build or return the variable that holds the static chain within
>     INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>
> @@ -310,9 +332,14 @@
>       Note also that it's represented as a parameter.  This is more
>       close to the truth, since the initial value does come from
>       the caller.  */
> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
> +      decl = build_decl
> +               (PARM_DECL, get_identifier (static_link_var_name), type);
> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>        DECL_ARTIFICIAL (decl) = 1;
> -      DECL_IGNORED_P (decl) = 1;
> +
> +      /* m3gdb needs to know about this variable. */
> +      DECL_IGNORED_P (decl) = 0;
> +
>        TREE_USED (decl) = 1;
>        DECL_CONTEXT (decl) = info->context;
>        DECL_ARG_TYPE (decl) = type;
> @@ -326,7 +353,11 @@
>    return decl;
>  }
>
> -/* Build or return the field within the non-local frame state that holds
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */
> +static const char * static_link_copy_field_name = "_static_link_copy_field";
> +
> +/* Build or return the field within the non-local frame struct that holds
>     the static chain for INFO->CONTEXT.  This is the way to walk back up
>     multiple nesting levels.  */
>
> @@ -339,10 +370,12 @@
>        tree type = build_pointer_type (get_frame_type (info->outer));
>
>        field = make_node (FIELD_DECL);
> -      DECL_NAME (field) = get_identifier ("__chain");
> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>        TREE_TYPE (field) = type;
>        DECL_ALIGN (field) = TYPE_ALIGN (type);
>        DECL_NONADDRESSABLE_P (field) = 1;
> +      /* m3gdb should know about this field. */
> +      DECL_IGNORED_P (field) = 0;
>
>        insert_field_into_struct (get_frame_type (info), field);
>
> @@ -465,7 +498,7 @@
>    return *slot;
>  }
>
> -/* Build or return the field within the non-local frame state that holds
> +/* Build or return the field within the non-local frame struct that holds
>     the non-local goto "jmp_buf".  The buffer itself is maintained by the
>     rtl middle-end as dynamic stack space is allocated.  */
>
> @@ -1620,6 +1653,9 @@
>    switch (TREE_CODE (t))
>      {
>      case ADDR_EXPR:
> +      if (TREE_STATIC (t))
> +    break;
> +
>        /* Build
>         T.1 = &CHAIN->tramp;
>         T.2 = __builtin_adjust_trampoline (T.1);
> @@ -1714,6 +1750,22 @@
>      }
>        break;
>
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
>      case RETURN_EXPR:
>      case GIMPLE_MODIFY_STMT:
>      case WITH_SIZE_EXPR:
> @@ -1768,13 +1820,22 @@
>    return NULL_TREE;
>  }
>
> +static bool
> +debug_static_links (void)
> +{ return
> +    write_symbols != NO_DEBUG
> +    && debug_info_level != DINFO_LEVEL_NONE
> +    && debug_info_level != DINFO_LEVEL_TERSE;
> +
> +} /* debug_static_links */
> +
>  /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>     trampolines and call expressions.  On the way back up, determine if
>     a nested function actually uses its static chain; if not, remember that.  */
>
>  static void
>  convert_all_function_calls (struct nesting_info *root)
> -{
> +{
>    do
>      {
>        if (root->inner)
> @@ -1784,7 +1845,10 @@
>        walk_function (convert_call_expr, root);
>
>        /* If the function does not use a static chain, then remember that.  */
> -      if (root->outer && !root->chain_decl && !root->chain_field)
> +      if (root->outer && !root->chain_decl && !root->chain_field
> +/* REMOVE ME: */
> +          /* && !debug_static_links () */
> +         )
>      DECL_NO_STATIC_CHAIN (root->context) = 1;
>        else
>      gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
> @@ -1806,6 +1870,21 @@
>    tree context = root->context;
>    struct function *sf;
>
> +/* REMOVEME: */
> +  /* If this is a nested function and we are supporting debugging via
> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
> +     chain, even if the programmer's code doesn't use it. */
> +  if (false && root->outer && debug_static_links () )
> +    { tree static_chain_decl, temp, stmt;
> +      /* This is a desperate attempt to get later code generation to
> +         store the static link.  If it works, it'll be a miracle. */
> +      static_chain_decl = get_chain_decl (root);
> +      stmt = build_addr (static_chain_decl, root->context);
> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
> +      append_to_statement_list (stmt, &stmt_list);
> +    }
> +
>    /* If we created a non-local frame type or decl, we need to lay them
>       out at this time.  */
>    if (root->frame_type)
> @@ -1912,7 +1991,7 @@
>       proper BIND_EXPR.  */
>    if (root->new_local_var_chain)
>      declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
> -          false);
> +          true);
>    if (root->debug_var_chain)
>      declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>            true);
>
>
>
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 13:58:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 11:58:09 +0000
Subject: [M3devel] dbxout_static_chain_decl?
Message-ID: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>


Rodney, you added this function, along with a comment that says it doesn't actually work.
Does it work?
Does it accomplish anything?
Can I remove it and its calls?

/* Special-purpose function to write stabs for the static_chain_decl. 
?? So far, this is not working.? m3gdb needs the place in the activation
?? record where the SL is stored.? Right now, the SL is not necessarily
?? stored at all, but may just be kept in a register.? DECL_RTL and 
?? DECL_INCOMING_RTL may both have register expressions.? But stabs
?? entries for register variables, of kind N_RSYM, are currently ignored
?? by gdb in dbxread.c, and making it read them could create problems
?? elsewhere, because there can be other variables for which both an
?? N_RSYM and an N_LSYM stabs entry are created.?? 
*/ 
static int 
dbxout_static_chain_decl (tree decl) 

It was added 19 months ago by:
? http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9

as well, do we need the #if 0 code added then?

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 16:20:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 14:20:04 +0000
Subject: [M3devel] DECL_LANG_SPECIFIC and casts?
Message-ID: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>


Tony, this thing where we do:

? DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
...

????? tree var = (tree)DECL_LANG_SPECIFIC(index);


Is this running afoul of the gcc garbage collector?
? Seems likely.

And does it matter?
? Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
?assuming m3_write_globals is called near the end.


Thing is:
struct lang_identifier GTY(()) ...
union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
struct lang_type GTY(()) ...
typedef struct lang_decl GTY(()) ...
struct language_function GTY(()) ...


Which are nearly unused, cause me grief.
They have to be different for 4.5 vs. 4.2/4.3.
? Just the GTY needs to be moved to before the union/struct tag.


I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
? I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
?? aren't so small like ours so I'd rather not.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Wed May 26 16:26:32 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 26 May 2010 10:26:32 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>
References: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>
Message-ID: <88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>

On 26 May 2010, at 03:55, Jay K wrote:

> 
> I'm going to try to keep the code that seems to do anything, however:
> 
> 1) if (false && 
> 
>  I plan to remove that.
> 
> 
> 2)
> +      if (root->outer && !root->chain_decl && !root->chain_field
> +/* REMOVE ME: */ 
> +          /* && !debug_static_links () */ 
> +         )
> 
> 
> I can't find where that would apply, and it is commented out anyway so I'll remove it.
> 
> 
> I'm open to arguments though. :)
> 
> dbxout.c
> +#if 0
> +/* Code copied from 1.4.2.2: */ 
> 
> 
> I can cheaply enough keep that...should we really though?
> 
> 
> I really think we can reduce our changes.
> Enough type information should be passed around so that regular gdb works. Imho.

Possibly, but M3 has a very different notion of type to C.  Moreover, it is extremely valuable to have the M3 type ids there so that functionality can map back to the types in the M3 runtime system.  It would be possible to implement much of the m3gdb debugging support by calling back into the language run-time passing the language type ids instead of relying on hand-crafted C in m3gdb.  But I agree that more type information would be good, particularly for records.

>  And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
>   don't cause internal compiler errors. So that debug info might be generated on systems
>   that don't support stabs though granted they are few and minor (hppa64-hpux).
> Nested functions should be transformed to not be nested. Imho.

I don't understand this.  Nested functions must be nested in the sense that they have static chain information provided by gcc.

> Optimization should be allowed to inhibit debugging as much as it does for any other language.

What do you mean by this?

> 
> 
> I realize the type information getting around is probably a lot of work.
> And it is needed in m3back also, and probably not shared work.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Subject: m3cc static chain stuff
>> Date: Wed, 26 May 2010 06:05:25 +0000
>> 
>> 
>> Can any of this be removed?
>> Can we really not just use "unfold-nested-procs" like NT386?
>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>> generally a considered the responsibility of optimizers.
>> 
>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>> Maybe I'll try without.
>> 
>> 
>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
>> 
>> 
>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>> -   shared between INFO->CONTEXT and its nested functions.  This record will
>> -   not be complete until finalize_nesting_tree; up until that point we'll
>> +/* This must agree with the string defined by the same name in m3gdb, file
>> +   m3-util.c */
>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>> +
>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>> +   that is shared between INFO->CONTEXT and its nested functions.  This record
>> +   will not be complete until finalize_nesting_tree; up until that point we'll
>>    be adding fields as necessary.
>> 
>>    We also build the DECL that represents this frame in the function.  */
>> @@ -209,7 +224,8 @@
>>       free (name);
>> 
>>       info->frame_type = type;
>> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>> +      info->frame_decl
>> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>> 
>>       /* ??? Always make it addressable for now, since it is meant to
>>      be pointed to by the static chain pointer.  This pessimizes
>> @@ -218,6 +234,8 @@
>>      reachable, but the true pessimization is to create the non-
>>      local frame structure in the first place.  */
>>       TREE_ADDRESSABLE (info->frame_decl) = 1;
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (info->frame_decl) = 0;
>>     }
>>   return type;
>> }
>> @@ -290,6 +308,10 @@
>>   return *slot;
>> }
>> 
>> +/* This must agree with the string defined by the same name in m3gdb, file
>> +   m3_util.c */
>> +static const char * static_link_var_name = "_static_link_var";
>> +
>> /* Build or return the variable that holds the static chain within
>>    INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>> 
>> @@ -310,9 +332,14 @@
>>      Note also that it's represented as a parameter.  This is more
>>      close to the truth, since the initial value does come from
>>      the caller.  */
>> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>> +      decl = build_decl
>> +               (PARM_DECL, get_identifier (static_link_var_name), type);
>> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>       DECL_ARTIFICIAL (decl) = 1;
>> -      DECL_IGNORED_P (decl) = 1;
>> +
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (decl) = 0;
>> +
>>       TREE_USED (decl) = 1;
>>       DECL_CONTEXT (decl) = info->context;
>>       DECL_ARG_TYPE (decl) = type;
>> @@ -326,7 +353,11 @@
>>   return decl;
>> }
>> 
>> -/* Build or return the field within the non-local frame state that holds
>> +/* This must agree with the string defined by the same name in m3gdb, file
>> +   m3_util.c */
>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>> +
>> +/* Build or return the field within the non-local frame struct that holds
>>    the static chain for INFO->CONTEXT.  This is the way to walk back up
>>    multiple nesting levels.  */
>> 
>> @@ -339,10 +370,12 @@
>>       tree type = build_pointer_type (get_frame_type (info->outer));
>> 
>>       field = make_node (FIELD_DECL);
>> -      DECL_NAME (field) = get_identifier ("__chain");
>> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>       TREE_TYPE (field) = type;
>>       DECL_ALIGN (field) = TYPE_ALIGN (type);
>>       DECL_NONADDRESSABLE_P (field) = 1;
>> +      /* m3gdb should know about this field. */
>> +      DECL_IGNORED_P (field) = 0;
>> 
>>       insert_field_into_struct (get_frame_type (info), field);
>> 
>> @@ -465,7 +498,7 @@
>>   return *slot;
>> }
>> 
>> -/* Build or return the field within the non-local frame state that holds
>> +/* Build or return the field within the non-local frame struct that holds
>>    the non-local goto "jmp_buf".  The buffer itself is maintained by the
>>    rtl middle-end as dynamic stack space is allocated.  */
>> 
>> @@ -1620,6 +1653,9 @@
>>   switch (TREE_CODE (t))
>>     {
>>     case ADDR_EXPR:
>> +      if (TREE_STATIC (t))
>> +    break;
>> +
>>       /* Build
>>        T.1 = &CHAIN->tramp;
>>        T.2 = __builtin_adjust_trampoline (T.1);
>> @@ -1714,6 +1750,22 @@
>>     }
>>       break;
>> 
>> +    case STATIC_CHAIN_EXPR:
>> +      decl = TREE_OPERAND (t, 0);
>> +      target_context = decl_function_context (decl);
>> +      if (target_context)
>> +    {
>> +      if (info->context == target_context)
>> +        {
>> +          /* Make sure frame_decl gets created.  */
>> +          (void) get_frame_type (info);
>> +        }
>> +      *tp = get_static_chain (info, target_context, &wi->tsi);
>> +    }
>> +      else
>> +    *tp = null_pointer_node;
>> +      break;
>> +
>>     case RETURN_EXPR:
>>     case GIMPLE_MODIFY_STMT:
>>     case WITH_SIZE_EXPR:
>> @@ -1768,13 +1820,22 @@
>>   return NULL_TREE;
>> }
>> 
>> +static bool
>> +debug_static_links (void)
>> +{ return
>> +    write_symbols != NO_DEBUG
>> +    && debug_info_level != DINFO_LEVEL_NONE
>> +    && debug_info_level != DINFO_LEVEL_TERSE;
>> +
>> +} /* debug_static_links */
>> +
>> /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>>    trampolines and call expressions.  On the way back up, determine if
>>    a nested function actually uses its static chain; if not, remember that.  */
>> 
>> static void
>> convert_all_function_calls (struct nesting_info *root)
>> -{
>> +{
>>   do
>>     {
>>       if (root->inner)
>> @@ -1784,7 +1845,10 @@
>>       walk_function (convert_call_expr, root);
>> 
>>       /* If the function does not use a static chain, then remember that.  */
>> -      if (root->outer && !root->chain_decl && !root->chain_field)
>> +      if (root->outer && !root->chain_decl && !root->chain_field
>> +/* REMOVE ME: */
>> +          /* && !debug_static_links () */
>> +         )
>>     DECL_NO_STATIC_CHAIN (root->context) = 1;
>>       else
>>     gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>> @@ -1806,6 +1870,21 @@
>>   tree context = root->context;
>>   struct function *sf;
>> 
>> +/* REMOVEME: */
>> +  /* If this is a nested function and we are supporting debugging via
>> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
>> +     chain, even if the programmer's code doesn't use it. */
>> +  if (false && root->outer && debug_static_links () )
>> +    { tree static_chain_decl, temp, stmt;
>> +      /* This is a desperate attempt to get later code generation to
>> +         store the static link.  If it works, it'll be a miracle. */
>> +      static_chain_decl = get_chain_decl (root);
>> +      stmt = build_addr (static_chain_decl, root->context);
>> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>> +      append_to_statement_list (stmt, &stmt_list);
>> +    }
>> +
>>   /* If we created a non-local frame type or decl, we need to lay them
>>      out at this time.  */
>>   if (root->frame_type)
>> @@ -1912,7 +1991,7 @@
>>      proper BIND_EXPR.  */
>>   if (root->new_local_var_chain)
>>     declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>> -          false);
>> +          true);
>>   if (root->debug_var_chain)
>>     declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>           true);
>> 
>> 
>> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed May 26 16:28:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 26 May 2010 10:28:51 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
Message-ID: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>

We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible.  The only thing is that we also build closures, so the trampoline mechanisms should be avoided.


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 26 May 2010, at 02:05, Jay K wrote:

> 
> Can any of this be removed?
> Can we really not just use "unfold-nested-procs" like NT386?
> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
> generally a considered the responsibility of optimizers.
> 
> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
> Maybe I'll try without.
> 
> 
> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
> 
> 
> -/* Build or return the RECORD_TYPE that describes the frame state that is
> -   shared between INFO->CONTEXT and its nested functions.  This record will
> -   not be complete until finalize_nesting_tree; up until that point we'll
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3-util.c */ 
> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec"; 
> +
> +/* Build or return the RECORD_TYPE that describes the non-local frame struct 
> +   that is shared between INFO->CONTEXT and its nested functions.  This record 
> +   will not be complete until finalize_nesting_tree; up until that point we'll
>     be adding fields as necessary.
>  
>     We also build the DECL that represents this frame in the function.  */
> @@ -209,7 +224,8 @@
>        free (name);
>  
>        info->frame_type = type;
> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
> +      info->frame_decl 
> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>  
>        /* ??? Always make it addressable for now, since it is meant to
>       be pointed to by the static chain pointer.  This pessimizes
> @@ -218,6 +234,8 @@
>       reachable, but the true pessimization is to create the non-
>       local frame structure in the first place.  */
>        TREE_ADDRESSABLE (info->frame_decl) = 1;
> +      /* m3gdb needs to know about this variable. */ 
> +      DECL_IGNORED_P (info->frame_decl) = 0;  
>      }
>    return type;
>  }
> @@ -290,6 +308,10 @@
>    return *slot;
>  }
>  
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */ 
> +static const char * static_link_var_name = "_static_link_var"; 
> +
>  /* Build or return the variable that holds the static chain within
>     INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>  
> @@ -310,9 +332,14 @@
>       Note also that it's represented as a parameter.  This is more
>       close to the truth, since the initial value does come from 
>       the caller.  */
> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
> +      decl = build_decl 
> +               (PARM_DECL, get_identifier (static_link_var_name), type);
> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */ 
>        DECL_ARTIFICIAL (decl) = 1;
> -      DECL_IGNORED_P (decl) = 1;
> +
> +      /* m3gdb needs to know about this variable. */ 
> +      DECL_IGNORED_P (decl) = 0;
> +
>        TREE_USED (decl) = 1;
>        DECL_CONTEXT (decl) = info->context;
>        DECL_ARG_TYPE (decl) = type;
> @@ -326,7 +353,11 @@
>    return decl;
>  }
>  
> -/* Build or return the field within the non-local frame state that holds
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */ 
> +static const char * static_link_copy_field_name = "_static_link_copy_field"; 
> +
> +/* Build or return the field within the non-local frame struct that holds
>     the static chain for INFO->CONTEXT.  This is the way to walk back up
>     multiple nesting levels.  */
>  
> @@ -339,10 +370,12 @@
>        tree type = build_pointer_type (get_frame_type (info->outer));
>  
>        field = make_node (FIELD_DECL);
> -      DECL_NAME (field) = get_identifier ("__chain");
> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>        TREE_TYPE (field) = type;
>        DECL_ALIGN (field) = TYPE_ALIGN (type);
>        DECL_NONADDRESSABLE_P (field) = 1;
> +      /* m3gdb should know about this field. */ 
> +      DECL_IGNORED_P (field) = 0;  
>  
>        insert_field_into_struct (get_frame_type (info), field);
>  
> @@ -465,7 +498,7 @@
>    return *slot;
>  } 
>  
> -/* Build or return the field within the non-local frame state that holds
> +/* Build or return the field within the non-local frame struct that holds
>     the non-local goto "jmp_buf".  The buffer itself is maintained by the
>     rtl middle-end as dynamic stack space is allocated.  */
>  
> @@ -1620,6 +1653,9 @@
>    switch (TREE_CODE (t))
>      {
>      case ADDR_EXPR:
> +      if (TREE_STATIC (t))
> +    break;
> +
>        /* Build
>         T.1 = &CHAIN->tramp;
>         T.2 = __builtin_adjust_trampoline (T.1);
> @@ -1714,6 +1750,22 @@
>      }
>        break;
>  
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
>      case RETURN_EXPR:
>      case GIMPLE_MODIFY_STMT:
>      case WITH_SIZE_EXPR:
> @@ -1768,13 +1820,22 @@
>    return NULL_TREE;
>  }
>  
> +static bool
> +debug_static_links (void) 
> +{ return
> +    write_symbols != NO_DEBUG
> +    && debug_info_level != DINFO_LEVEL_NONE
> +    && debug_info_level != DINFO_LEVEL_TERSE;
> +
> +} /* debug_static_links */ 
> +
>  /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>     trampolines and call expressions.  On the way back up, determine if
>     a nested function actually uses its static chain; if not, remember that.  */
>  
>  static void
>  convert_all_function_calls (struct nesting_info *root)
> -{
> +{ 
>    do
>      {
>        if (root->inner)
> @@ -1784,7 +1845,10 @@
>        walk_function (convert_call_expr, root);
>  
>        /* If the function does not use a static chain, then remember that.  */
> -      if (root->outer && !root->chain_decl && !root->chain_field)
> +      if (root->outer && !root->chain_decl && !root->chain_field
> +/* REMOVE ME: */ 
> +          /* && !debug_static_links () */ 
> +         )
>      DECL_NO_STATIC_CHAIN (root->context) = 1;
>        else
>      gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
> @@ -1806,6 +1870,21 @@
>    tree context = root->context;
>    struct function *sf;
>  
> +/* REMOVEME: */ 
> +  /* If this is a nested function and we are supporting debugging via
> +     m3gdb, we always need a chain_decl, so m3gdb can find the static 
> +     chain, even if the programmer's code doesn't use it. */ 
> +  if (false && root->outer && debug_static_links () )
> +    { tree static_chain_decl, temp, stmt;
> +      /* This is a desperate attempt to get later code generation to 
> +         store the static link.  If it works, it'll be a miracle. */ 
> +      static_chain_decl = get_chain_decl (root); 
> +      stmt = build_addr (static_chain_decl, root->context); 
> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
> +      append_to_statement_list (stmt, &stmt_list);
> +    } 
> +
>    /* If we created a non-local frame type or decl, we need to lay them
>       out at this time.  */
>    if (root->frame_type)
> @@ -1912,7 +1991,7 @@
>       proper BIND_EXPR.  */
>    if (root->new_local_var_chain)
>      declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
> -          false);
> +          true);
>    if (root->debug_var_chain)
>      declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>            true);
> 
> 
> 		 	   		  

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

From jay.krell at cornell.edu  Wed May 26 17:02:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 15:02:10 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
Message-ID: <COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>


> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 10:28:51 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
>
>
> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.


Right..for those that don't know..


There's no "good" efficient way to implement nested functions.
Our implementation is pretty "bad".
gcc's implementation is pretty "bad".
They are different.


gcc (Tony mentions "trampoline"):
In particular, taking the address of a nested function
involves runtime code generation on the stack.
These days, running code on the stack is "difficult".
On some systems, you do mprotect() to make that part of the stack executable.
On other systems, you just can't do it (iPhone).
On older systems, no problem. It is simple and efficient.


Modula-3:
Whenever we go to call a function pointer, we first see if it start with a 4 or 8 byte -1.
If so, it is our "closure" thingy, and the -1 is followed
I guess by an actual function pointer and a static link.
The static link is loaded wherever and the function called.


Other systems (see modern ATL on Windows) allocate executable
memory not on the stack. Not even regular heap is executable
generally any longer though, one need to VirtualAlloc or mmap or such.


This is a powerful mechanism in general, you can do stuff like
runtime "currying".


Pointers to nested Modula-3 function cannot be passed off
as function pointers to other languages.
? But hey, at least we can write nested functions and pass
??? them off to ourselves. Interop with C would just be bonus?


Calling function pointers in Modula-3 is slowed down
everywhere, in case the function pointer is nested.
I think.


-1 must be ensured to be invalid code.
Or we could make it a more visible part of porting.
?You know -- it could be per-target and folks would have
?to experiment with each target to find a good sequence,
?that is cheap to detect and guaranteed invalid.
?(ie: 0 might be better than -1!)


Could possibly replace the -1 with an actual function pointer
that is always called.
But then pointers to non-nested functions also wouldn't
interoperate with C.


I think there's something more to the mechanisms than I realize.
The "static link" must survive calls out to non-nested functions
or somesuch.


Anyway, while I think our mechanism is pretty clearly flawed,
it seems to be slightly less bad than gcc's.


Perhaps we should invest in what ATL does though and
dynamically allocate executable memory not on the stack?
Still, an "open" iPhone is probably better with the current scheme.
Most other systems should be ok either way.


I think there is a bit of 4.3=>4.5 that needs closer attention
and isn't obvious, this part:

+??? case STATIC_CHAIN_EXPR:
+????? decl = TREE_OPERAND (t, 0);
+????? target_context = decl_function_context (decl);
+????? if (target_context)
+??? {
+??? ? if (info->context == target_context)
+??? ??? {
+??? ????? /* Make sure frame_decl gets created.? */
+??? ????? (void) get_frame_type (info);
+??? ??? }
+??? ? *tp = get_static_chain (info, target_context, &wi->tsi);
+??? }
+????? else
+??? *tp = null_pointer_node;
+????? break;
+

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 17:13:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 15:13:38 +0000
Subject: [M3devel] closure marker
Message-ID: <COL101-W251CA496DF1BD58A8AEB48E6E90@phx.gbl>


As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
64bit systems that care about alignment pay quite a penality imho.


I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.


If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.


I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
? Do they have 4 byte instructions, that are always 4 byte aligned?


IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.


More general might be
? Target.ClosureElementSize? (bits)
? Target.ClosureElementCount? 


IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
Whereas most others would have Target.ClosureElementSize? = 32, Target.ClosureElementSize? = 1.
ClosureElementSize would be chosen to be match guaranteed code alignment.



? - Jay

 		 	   		  

From jay.krell at cornell.edu  Wed May 26 18:45:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 16:45:06 +0000
Subject: [M3devel] closure marker
Message-ID: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>


A little bit of research done (just searching the web):
?Mips, Alpha, PowerPC, HPPA, ARM, SPARC


all appear to use a 32bit instruction
presumably aligned but I couldn't confirm for all of them.
? It seems likely that if the processor cares about data alignment, then code will be aligned the same.


Looks like SH has 16bit instructions.


I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
With IA64 the expected exception with size=64bits, count=2.
? It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
? We can revisit at that time.
And really size=64, count=1 might suffice.

I'm a little torn.
A 64bit marker is more certain.
Code has been this way forever.
etc.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Subject: closure marker
> Date: Wed, 26 May 2010 15:13:38 +0000
>
>
> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
> 64bit systems that care about alignment pay quite a penality imho.
>
>
> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>
>
> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>
>
> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>   Do they have 4 byte instructions, that are always 4 byte aligned?
>
>
> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>
>
> More general might be
>   Target.ClosureElementSize  (bits)
>   Target.ClosureElementCount
>
>
> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
> Whereas most others would have Target.ClosureElementSize  = 32, Target.ClosureElementSize  = 1.
> ClosureElementSize would be chosen to be match guaranteed code alignment.
>
>
>
>   - Jay
>
>
 		 	   		  

From hendrik at topoi.pooq.com  Wed May 26 15:25:25 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 26 May 2010 09:25:25 -0400
Subject: [M3devel] OS for CM3
In-Reply-To: <729398.10895.qm@web23605.mail.ird.yahoo.com>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
	<729398.10895.qm@web23605.mail.ird.yahoo.com>
Message-ID: <20100526132524.GB18812@topoi.pooq.com>

On Tue, May 25, 2010 at 04:07:24AM +0000, Daniel Alejandro Benavides D. wrote:
> Hi:
> if easy of administration is what you are looking for maybe a bsd 
> flavour a is the right choice of use probably it would be a linux 
> distro but a common sense of easy administration and use like ubuntu 
> rh/centos server or why not a gentoo or archlinux if customization is 
> what you want to add more cores linux will support up to 1024 and the 
> small or medium size servers are commonly used in this servers sizes I 
> guess you have a good choice to take advantage, how many does support 
> Win server 2k3 (up to 64?) an another bsd up to how many?  
> 
> Hope it helps, thanks in advance

The next release of Debian is supposed to run on a BSD kernel as one of 
its platforms.  So there will be Linux and nonLinux distros for Debian.

-- hendrik


From hosking at cs.purdue.edu  Wed May 26 22:13:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 26 May 2010 16:13:29 -0400
Subject: [M3devel] DECL_LANG_SPECIFIC and casts?
In-Reply-To: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>
References: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>
Message-ID: <8EDE1A93-0507-43C2-8DF4-9291B1C4C8E4@cs.purdue.edu>

Why would this be problematic?  We need to retain it for later use, and I remember making sure that this worked.  Does the collector somehow delete the target?

On 26 May 2010, at 10:20, Jay K wrote:

> 
> Tony, this thing where we do:
> 
>   DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
> ...
> 
>       tree var = (tree)DECL_LANG_SPECIFIC(index);
> 
> 
> Is this running afoul of the gcc garbage collector?
>   Seems likely.
> 
> And does it matter?
>   Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
>  assuming m3_write_globals is called near the end.
> 
> 
> Thing is:
> struct lang_identifier GTY(()) ...
> union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
> struct lang_type GTY(()) ...
> typedef struct lang_decl GTY(()) ...
> struct language_function GTY(()) ...
> 
> 
> Which are nearly unused, cause me grief.
> They have to be different for 4.5 vs. 4.2/4.3.
>   Just the GTY needs to be moved to before the union/struct tag.
> 
> 
> I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
>   I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
>    aren't so small like ours so I'd rather not.
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Wed May 26 23:54:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 21:54:45 +0000
Subject: [M3devel] DECL_LANG_SPECIFIC and casts?
In-Reply-To: <8EDE1A93-0507-43C2-8DF4-9291B1C4C8E4@cs.purdue.edu>
References: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>,
	<8EDE1A93-0507-43C2-8DF4-9291B1C4C8E4@cs.purdue.edu>
Message-ID: <COL101-W43FC8D66C4B28F3CEC856AE6E90@phx.gbl>


Nevermind.
In 4.3 you have to say
struct foo GTY(())

in 4.5 you have to say struct GTY foo(());

Just on the type/field declarations.
Variables have the same syntax.

I asssume 4.2 matches 4.3 but I have to double check.

Apple, therefore iPhone, is still on 4.2.
I don't want to merge.
I'd rather keep 4.2/4.5 compatible code.

So if possible, would like to remove this stuff.
But doesn't seem possible.
Instead I'll move it to 4.2/4.5-specific files.

Unless by chance 4.2 is ok with the 4.5 form. 4.3 isn't.
Unfortunate.

? - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 16:13:29 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] DECL_LANG_SPECIFIC and casts?
>
> Why would this be problematic? We need to retain it for later use, and I remember making sure that this worked. Does the collector somehow delete the target?
>
> On 26 May 2010, at 10:20, Jay K wrote:
>
>>
>> Tony, this thing where we do:
>>
>> DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
>> ...
>>
>> tree var = (tree)DECL_LANG_SPECIFIC(index);
>>
>>
>> Is this running afoul of the gcc garbage collector?
>> Seems likely.
>>
>> And does it matter?
>> Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
>> assuming m3_write_globals is called near the end.
>>
>>
>> Thing is:
>> struct lang_identifier GTY(()) ...
>> union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
>> struct lang_type GTY(()) ...
>> typedef struct lang_decl GTY(()) ...
>> struct language_function GTY(()) ...
>>
>>
>> Which are nearly unused, cause me grief.
>> They have to be different for 4.5 vs. 4.2/4.3.
>> Just the GTY needs to be moved to before the union/struct tag.
>>
>>
>> I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
>> I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
>> aren't so small like ours so I'd rather not.
>>
>>
>> - Jay
>>
>
 		 	   		  

From rodney_bates at lcwb.coop  Thu May 27 00:37:07 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 17:37:07 -0500
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>
Message-ID: <4BFDA293.9080503@lcwb.coop>

I left it in because it is a work in progress.  I *really* want to get it to
work, and I don't what to have to reinvent what is already there when I get
to it.  I use nested procedures extensively in certain situations, and good
debugger support of them is important to me.  It all works fine on older code
generators than the gcc that added tree-nested.c.

Jay K wrote:
> Rodney, you added this function, along with a comment that says it doesn't actually work.
> Does it work?
> Does it accomplish anything?
> Can I remove it and its calls?
> 
> /* Special-purpose function to write stabs for the static_chain_decl. 
>    So far, this is not working.  m3gdb needs the place in the activation
>    record where the SL is stored.  Right now, the SL is not necessarily
>    stored at all, but may just be kept in a register.  DECL_RTL and 
>    DECL_INCOMING_RTL may both have register expressions.  But stabs
>    entries for register variables, of kind N_RSYM, are currently ignored
>    by gdb in dbxread.c, and making it read them could create problems
>    elsewhere, because there can be other variables for which both an
>    N_RSYM and an N_LSYM stabs entry are created.   
> */ 
> static int 
> dbxout_static_chain_decl (tree decl) 
> 
> It was added 19 months ago by:
>   http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
> 
> as well, do we need the #if 0 code added then?
> 
>  - Jay
>  		 	   		  


From jay.krell at cornell.edu  Thu May 27 00:53:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 22:53:24 +0000
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <4BFDA293.9080503@lcwb.coop>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>,
	<4BFDA293.9080503@lcwb.coop>
Message-ID: <COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>


Rodney, When you get back to it, can you just dig it out of history?
 
 
I still think we should try to avoid gcc's nested function functionality.
 
 
Where you use the static chain, not using the nested function functionality should
"automatically" be debuggable -- "automatic" as in, once the work is done
in the frontend to transform out nesting.
 
 
"debuggable" as in, you could follow the links yourself in the debugger.
The debugger need not search lexically nested functions that have function
calls dividing them.
 
 
?
 
 
There's stuff I still need to understand better -- particularly the affect of nested functions
on non-nested functions. Is there *always* an extra parameter to *all* functions?
It appears so.
And I haven't figured out how to merge with 4.5 what I think achieves that.
 
 
Maybe a good test of test cases here?
 
 
 
 - Jay


----------------------------------------
> Date: Wed, 26 May 2010 17:37:07 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
> I left it in because it is a work in progress. I *really* want to get it to
> work, and I don't what to have to reinvent what is already there when I get
> to it. I use nested procedures extensively in certain situations, and good
> debugger support of them is important to me. It all works fine on older code
> generators than the gcc that added tree-nested.c.
>
> Jay K wrote:
>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>> Does it work?
>> Does it accomplish anything?
>> Can I remove it and its calls?
>>
>> /* Special-purpose function to write stabs for the static_chain_decl.
>> So far, this is not working. m3gdb needs the place in the activation
>> record where the SL is stored. Right now, the SL is not necessarily
>> stored at all, but may just be kept in a register. DECL_RTL and
>> DECL_INCOMING_RTL may both have register expressions. But stabs
>> entries for register variables, of kind N_RSYM, are currently ignored
>> by gdb in dbxread.c, and making it read them could create problems
>> elsewhere, because there can be other variables for which both an
>> N_RSYM and an N_LSYM stabs entry are created.
>> */
>> static int
>> dbxout_static_chain_decl (tree decl)
>>
>> It was added 19 months ago by:
>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>
>> as well, do we need the #if 0 code added then?
>>
>> - Jay
>> 		 	   		  

From rodney_bates at lcwb.coop  Thu May 27 01:04:42 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 18:04:42 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>
Message-ID: <4BFDA90A.3050105@lcwb.coop>



Jay K wrote:
>> From: hosking at cs.purdue.edu
>> Date: Wed, 26 May 2010 10:28:51 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>>
>>
>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, 

whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
> 
> 
> Right..for those that don't know..
> 
> 
> There's no "good" efficient way to implement nested functions.
> Our implementation is pretty "bad".
> gcc's implementation is pretty "bad".

I think this is far too critical.  The inefficiencies you see are
minor.  Certainly no worse than the implementation of dispatching
methods of objects, something the world is gaga about.  And the
inefficiencies I think you are worrying about only arise when
you pass procedures as parameters.




> They are different.
> 
> 
> gcc (Tony mentions "trampoline"):
> In particular, taking the address of a nested function
> involves runtime code generation on the stack.
> These days, running code on the stack is "difficult".
> On some systems, you do mprotect() to make that part of the stack executable.
> On other systems, you just can't do it (iPhone).
> On older systems, no problem. It is simple and efficient.
> 

Yes, that is one consequence of trampolines.  There has to be a place
to generate code at runtime that will be executable, and a way to
memory-manage it.

> 
> Modula-3:
> Whenever we go to call a function pointer, we first see if it start with a 4 or 8 byte -1.
> If so, it is our "closure" thingy, and the -1 is followed
> I guess by an actual function pointer and a static link.
> The static link is loaded wherever and the function called.
> 
> 
> Other systems (see modern ATL on Windows) allocate executable
> memory not on the stack. Not even regular heap is executable
> generally any longer though, one need to VirtualAlloc or mmap or such.
> 
> 
> This is a powerful mechanism in general, you can do stuff like
> runtime "currying".
> 
> 
> Pointers to nested Modula-3 function cannot be passed off
> as function pointers to other languages.
>   But hey, at least we can write nested functions and pass
>     them off to ourselves. Interop with C would just be bonus?
> 

But if we used trampolines instead of our form of closures, they
could be.  Or, more generally, if we used the same mechanism as
"other languages", they could be.

> 
> Calling function pointers in Modula-3 is slowed down
> everywhere, in case the function pointer is nested.
> I think.

Only calling procedures through a procedure-typed _parameter_ is
slowed down.  Calling through a procedure-typed _variable_ is known,
by language semantics, always to be to a top-level procedure, and
is as fast as a C call to a non-nested function pointer.
Note that, when calling a function pointer to a nested procedure,
trampolines are surely about as fast as you can get.

> 
> 
> -1 must be ensured to be invalid code.
> Or we could make it a more visible part of porting.
>  You know -- it could be per-target and folks would have
>  to experiment with each target to find a good sequence,
>  that is cheap to detect and guaranteed invalid.
>  (ie: 0 might be better than -1!)
> 
> 
> Could possibly replace the -1 with an actual function pointer
> that is always called.
> But then pointers to non-nested functions also wouldn't
> interoperate with C.

I don't understand what mechanism you are proposing here.  Taken
literally, it sounds like a trampoline to me, which would allow
non-nested and nested function pointers to interoperate with C.

> 
> 
> I think there's something more to the mechanisms than I realize.
> The "static link" must survive calls out to non-nested functions
> or somesuch.
> 
> 
> Anyway, while I think our mechanism is pretty clearly flawed,
> it seems to be slightly less bad than gcc's.
> 

I'm not sure what you mean by flawed, but if you mean it doesn't
correctly implement language semantics, that is not true.  It works
correctly.  So do trampolines, although in C (for other reasons that
are independent of what mechanism you use for function pointers),
the semantics of the language have a big hole.  As usual, C passes
the buck by defining this as "undefined".

> 
> Perhaps we should invest in what ATL does though and
> dynamically allocate executable memory not on the stack?

If there is a way to do this, then trampolines can be made to work.
What does gcc do now on such targets?

> Still, an "open" iPhone is probably better with the current scheme.
> Most other systems should be ok either way.
> 
> 
> I think there is a bit of 4.3=>4.5 that needs closer attention
> and isn't obvious, this part:
> 
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
> 
>  - Jay
>  

Jay, you have made it clear repeatedly that you only use gdb, and
never m3gdb, so obviously, Modula-3-specific support is of no importance
to you.  That's OK, but please don't spoil the game for those of us
who do care about it by ripping stuff out of the compiler that m3gdb
needs.  Even when it isn't fully working yet.

		 	   		


From jay.krell at cornell.edu  Thu May 27 00:56:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 22:56:19 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>
References: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>,
	<88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>
Message-ID: <COL101-W50960886C3E99F184DBA1CE6E90@phx.gbl>


>> Nested functions should be transformed to not be nested. Imho.
 
> I don't understand this. Nested functions must be nested in the sense that
> they have static chain information provided by gcc.
 
 
 
Can it be achieved by adding an extra parameter instead?
 
 
 
>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
> What do you mean by this?
 
 
 
It looks like we inhibit optimization if -g is specified.
Like we preserve unused static chains.
This is has been discussed and I have to look at the code more..
Generating debug information should not inhibit optimization.
 
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 10:26:32 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
> On 26 May 2010, at 03:55, Jay K wrote:
>
>>
>> I'm going to try to keep the code that seems to do anything, however:
>>
>> 1) if (false &&
>>
>> I plan to remove that.
>>
>>
>> 2)
>> + if (root->outer && !root->chain_decl && !root->chain_field
>> +/* REMOVE ME: */
>> + /* && !debug_static_links () */
>> + )
>>
>>
>> I can't find where that would apply, and it is commented out anyway so I'll remove it.
>>
>>
>> I'm open to arguments though. :)
>>
>> dbxout.c
>> +#if 0
>> +/* Code copied from 1.4.2.2: */
>>
>>
>> I can cheaply enough keep that...should we really though?
>>
>>
>> I really think we can reduce our changes.
>> Enough type information should be passed around so that regular gdb works. Imho.
>
> Possibly, but M3 has a very different notion of type to C. Moreover, it is extremely valuable to have the M3 type ids there so that functionality can map back to the types in the M3 runtime system. It would be possible to implement much of the m3gdb debugging support by calling back into the language run-time passing the language type ids instead of relying on hand-crafted C in m3gdb. But I agree that more type information would be good, particularly for records.
>
>> And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
>> don't cause internal compiler errors. So that debug info might be generated on systems
>> that don't support stabs though granted they are few and minor (hppa64-hpux).
>> Nested functions should be transformed to not be nested. Imho.
>
> I don't understand this. Nested functions must be nested in the sense that they have static chain information provided by gcc.
>
>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
>
> What do you mean by this?
>
>>
>>
>> I realize the type information getting around is probably a lot of work.
>> And it is needed in m3back also, and probably not shared work.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: m3cc static chain stuff
>>> Date: Wed, 26 May 2010 06:05:25 +0000
>>>
>>>
>>> Can any of this be removed?
>>> Can we really not just use "unfold-nested-procs" like NT386?
>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>> generally a considered the responsibility of optimizers.
>>>
>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>> Maybe I'll try without.
>>>
>>>
>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>
>>>
>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> + m3-util.c */
>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>> +
>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>> be adding fields as necessary.
>>>
>>> We also build the DECL that represents this frame in the function. */
>>> @@ -209,7 +224,8 @@
>>> free (name);
>>>
>>> info->frame_type = type;
>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>> + info->frame_decl
>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>
>>> /* ??? Always make it addressable for now, since it is meant to
>>> be pointed to by the static chain pointer. This pessimizes
>>> @@ -218,6 +234,8 @@
>>> reachable, but the true pessimization is to create the non-
>>> local frame structure in the first place. */
>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>> + /* m3gdb needs to know about this variable. */
>>> + DECL_IGNORED_P (info->frame_decl) = 0;
>>> }
>>> return type;
>>> }
>>> @@ -290,6 +308,10 @@
>>> return *slot;
>>> }
>>>
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> + m3_util.c */
>>> +static const char * static_link_var_name = "_static_link_var";
>>> +
>>> /* Build or return the variable that holds the static chain within
>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>
>>> @@ -310,9 +332,14 @@
>>> Note also that it's represented as a parameter. This is more
>>> close to the truth, since the initial value does come from
>>> the caller. */
>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>> + decl = build_decl
>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>> DECL_ARTIFICIAL (decl) = 1;
>>> - DECL_IGNORED_P (decl) = 1;
>>> +
>>> + /* m3gdb needs to know about this variable. */
>>> + DECL_IGNORED_P (decl) = 0;
>>> +
>>> TREE_USED (decl) = 1;
>>> DECL_CONTEXT (decl) = info->context;
>>> DECL_ARG_TYPE (decl) = type;
>>> @@ -326,7 +353,11 @@
>>> return decl;
>>> }
>>>
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> + m3_util.c */
>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>> +
>>> +/* Build or return the field within the non-local frame struct that holds
>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>> multiple nesting levels. */
>>>
>>> @@ -339,10 +370,12 @@
>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>
>>> field = make_node (FIELD_DECL);
>>> - DECL_NAME (field) = get_identifier ("__chain");
>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>> TREE_TYPE (field) = type;
>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>> DECL_NONADDRESSABLE_P (field) = 1;
>>> + /* m3gdb should know about this field. */
>>> + DECL_IGNORED_P (field) = 0;
>>>
>>> insert_field_into_struct (get_frame_type (info), field);
>>>
>>> @@ -465,7 +498,7 @@
>>> return *slot;
>>> }
>>>
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* Build or return the field within the non-local frame struct that holds
>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>> rtl middle-end as dynamic stack space is allocated. */
>>>
>>> @@ -1620,6 +1653,9 @@
>>> switch (TREE_CODE (t))
>>> {
>>> case ADDR_EXPR:
>>> + if (TREE_STATIC (t))
>>> + break;
>>> +
>>> /* Build
>>> T.1 = &CHAIN->tramp;
>>> T.2 = __builtin_adjust_trampoline (T.1);
>>> @@ -1714,6 +1750,22 @@
>>> }
>>> break;
>>>
>>> + case STATIC_CHAIN_EXPR:
>>> + decl = TREE_OPERAND (t, 0);
>>> + target_context = decl_function_context (decl);
>>> + if (target_context)
>>> + {
>>> + if (info->context == target_context)
>>> + {
>>> + /* Make sure frame_decl gets created. */
>>> + (void) get_frame_type (info);
>>> + }
>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>> + }
>>> + else
>>> + *tp = null_pointer_node;
>>> + break;
>>> +
>>> case RETURN_EXPR:
>>> case GIMPLE_MODIFY_STMT:
>>> case WITH_SIZE_EXPR:
>>> @@ -1768,13 +1820,22 @@
>>> return NULL_TREE;
>>> }
>>>
>>> +static bool
>>> +debug_static_links (void)
>>> +{ return
>>> + write_symbols != NO_DEBUG
>>> + && debug_info_level != DINFO_LEVEL_NONE
>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>> +
>>> +} /* debug_static_links */
>>> +
>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>> trampolines and call expressions. On the way back up, determine if
>>> a nested function actually uses its static chain; if not, remember that. */
>>>
>>> static void
>>> convert_all_function_calls (struct nesting_info *root)
>>> -{
>>> +{
>>> do
>>> {
>>> if (root->inner)
>>> @@ -1784,7 +1845,10 @@
>>> walk_function (convert_call_expr, root);
>>>
>>> /* If the function does not use a static chain, then remember that. */
>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>> +/* REMOVE ME: */
>>> + /* && !debug_static_links () */
>>> + )
>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>> else
>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>> @@ -1806,6 +1870,21 @@
>>> tree context = root->context;
>>> struct function *sf;
>>>
>>> +/* REMOVEME: */
>>> + /* If this is a nested function and we are supporting debugging via
>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>> + chain, even if the programmer's code doesn't use it. */
>>> + if (false && root->outer && debug_static_links () )
>>> + { tree static_chain_decl, temp, stmt;
>>> + /* This is a desperate attempt to get later code generation to
>>> + store the static link. If it works, it'll be a miracle. */
>>> + static_chain_decl = get_chain_decl (root);
>>> + stmt = build_addr (static_chain_decl, root->context);
>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>> + append_to_statement_list (stmt, &stmt_list);
>>> + }
>>> +
>>> /* If we created a non-local frame type or decl, we need to lay them
>>> out at this time. */
>>> if (root->frame_type)
>>> @@ -1912,7 +1991,7 @@
>>> proper BIND_EXPR. */
>>> if (root->new_local_var_chain)
>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>> - false);
>>> + true);
>>> if (root->debug_var_chain)
>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>> true);
>>>
>>>
>>>
>>
> 		 	   		  

From rodney_bates at lcwb.coop  Thu May 27 01:14:34 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 18:14:34 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
Message-ID: <4BFDAB5A.6000304@lcwb.coop>



Tony Hosking wrote:
> We should endeavour to use the same functionality that the C compiler 
> uses for its own nested functions, whereever possible.  The only thing 
> is that we also build closures, so the trampoline mechanisms should be 
> avoided.

I don't follow the last part of this argument.  If we follow the first
principle, we would just use trampolines, since they are the same
mechanism the C compiler uses.  And the only place they are not possible
are places where they won't work for C either (e.g., a target where there
is no place to construct code at runtime and have it be executable).
The mere fact that we "also build closures" is not a necessity, just
the reflection of the design decision to use the closure mechanism
instead of trampolines.

OTHO, despite all the positive things I have said here and in another post
about trampolines, I don't favor using them, because they would make m3gdb
support a lot more difficult.  m3gdb needs to be able to both read and
construct closures/trampolines, whichever.  Closures are almost target-
independent, except for the native word size, which is already easily
available to m3gdb.  Trampolines are going to be different for every
instruction set, and the ones constructed by compiled code, at least,
could even change with compiler version.  m3gdb would need a _lot_ of
highly target-dependent code to handle them.

> 
> 
> 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 26 May 2010, at 02:05, Jay K wrote:
> 
>>
>> Can any of this be removed?
>> Can we really not just use "unfold-nested-procs" like NT386?
>> We'd just lose a little bit of optimization, in rare cases, stop 
>> paying a bad cost/benefit ratio?
>> Part of this is actually *deoptimization*. If the compiler decides the 
>> values aren't used, then it should
>> be allowed to remove them. That is normal. Wanting to unused stuff in 
>> the debugger isn't
>> generally a considered the responsibility of optimizers.
>>
>> Therefore -- we could "unfold", remove our diffs, and gain some 
>> optimization and some deoptimization.
>> Maybe I'll try without.
>>
>>
>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c 
>> /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 
>> 09:36:43.000000000 -0800
>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 
>> 22:27:58.000000000 -0700
>>
>>
>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>> -   shared between INFO->CONTEXT and its nested functions.  This 
>> record will
>> -   not be complete until finalize_nesting_tree; up until that point we'll
>> +/* This must agree with the string defined by the same name in m3gdb, 
>> file
>> +   m3-util.c */
>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>> +
>> +/* Build or return the RECORD_TYPE that describes the non-local frame 
>> struct
>> +   that is shared between INFO->CONTEXT and its nested functions.  
>> This record
>> +   will not be complete until finalize_nesting_tree; up until that 
>> point we'll
>>     be adding fields as necessary.
>>  
>>     We also build the DECL that represents this frame in the function.  */
>> @@ -209,7 +224,8 @@
>>        free (name);
>>  
>>        info->frame_type = type;
>> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>> +      info->frame_decl
>> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>  
>>        /* ??? Always make it addressable for now, since it is meant to
>>       be pointed to by the static chain pointer.  This pessimizes
>> @@ -218,6 +234,8 @@
>>       reachable, but the true pessimization is to create the non-
>>       local frame structure in the first place.  */
>>        TREE_ADDRESSABLE (info->frame_decl) = 1;
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (info->frame_decl) = 0; 
>>      }
>>    return type;
>>  }
>> @@ -290,6 +308,10 @@
>>    return *slot;
>>  }
>>  
>> +/* This must agree with the string defined by the same name in m3gdb, 
>> file
>> +   m3_util.c */
>> +static const char * static_link_var_name = "_static_link_var";
>> +
>>  /* Build or return the variable that holds the static chain within
>>     INFO->CONTEXT.  This variable may only be used within 
>> INFO->CONTEXT.  */
>>  
>> @@ -310,9 +332,14 @@
>>       Note also that it's represented as a parameter.  This is more
>>       close to the truth, since the initial value does come from
>>       the caller.  */
>> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>> +      decl = build_decl
>> +               (PARM_DECL, get_identifier (static_link_var_name), type);
>> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout 
>> needs it. */
>>        DECL_ARTIFICIAL (decl) = 1;
>> -      DECL_IGNORED_P (decl) = 1;
>> +
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (decl) = 0;
>> +
>>        TREE_USED (decl) = 1;
>>        DECL_CONTEXT (decl) = info->context;
>>        DECL_ARG_TYPE (decl) = type;
>> @@ -326,7 +353,11 @@
>>    return decl;
>>  }
>>  
>> -/* Build or return the field within the non-local frame state that holds
>> +/* This must agree with the string defined by the same name in m3gdb, 
>> file
>> +   m3_util.c */
>> +static const char * static_link_copy_field_name = 
>> "_static_link_copy_field";
>> +
>> +/* Build or return the field within the non-local frame struct that holds
>>     the static chain for INFO->CONTEXT.  This is the way to walk back up
>>     multiple nesting levels.  */
>>  
>> @@ -339,10 +370,12 @@
>>        tree type = build_pointer_type (get_frame_type (info->outer));
>>  
>>        field = make_node (FIELD_DECL);
>> -      DECL_NAME (field) = get_identifier ("__chain");
>> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>        TREE_TYPE (field) = type;
>>        DECL_ALIGN (field) = TYPE_ALIGN (type);
>>        DECL_NONADDRESSABLE_P (field) = 1;
>> +      /* m3gdb should know about this field. */
>> +      DECL_IGNORED_P (field) = 0; 
>>  
>>        insert_field_into_struct (get_frame_type (info), field);
>>  
>> @@ -465,7 +498,7 @@
>>    return *slot;
>>  }
>>  
>> -/* Build or return the field within the non-local frame state that holds
>> +/* Build or return the field within the non-local frame struct that holds
>>     the non-local goto "jmp_buf".  The buffer itself is maintained by the
>>     rtl middle-end as dynamic stack space is allocated.  */
>>  
>> @@ -1620,6 +1653,9 @@
>>    switch (TREE_CODE (t))
>>      {
>>      case ADDR_EXPR:
>> +      if (TREE_STATIC (t))
>> +    break;
>> +
>>        /* Build
>>         T.1 = &CHAIN->tramp;
>>         T.2 = __builtin_adjust_trampoline (T.1);
>> @@ -1714,6 +1750,22 @@
>>      }
>>        break;
>>  
>> +    case STATIC_CHAIN_EXPR:
>> +      decl = TREE_OPERAND (t, 0);
>> +      target_context = decl_function_context (decl);
>> +      if (target_context)
>> +    {
>> +      if (info->context == target_context)
>> +        {
>> +          /* Make sure frame_decl gets created.  */
>> +          (void) get_frame_type (info);
>> +        }
>> +      *tp = get_static_chain (info, target_context, &wi->tsi);
>> +    }
>> +      else
>> +    *tp = null_pointer_node;
>> +      break;
>> +
>>      case RETURN_EXPR:
>>      case GIMPLE_MODIFY_STMT:
>>      case WITH_SIZE_EXPR:
>> @@ -1768,13 +1820,22 @@
>>    return NULL_TREE;
>>  }
>>  
>> +static bool
>> +debug_static_links (void)
>> +{ return
>> +    write_symbols != NO_DEBUG
>> +    && debug_info_level != DINFO_LEVEL_NONE
>> +    && debug_info_level != DINFO_LEVEL_TERSE;
>> +
>> +} /* debug_static_links */
>> +
>>  /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>>     trampolines and call expressions.  On the way back up, determine if
>>     a nested function actually uses its static chain; if not, remember 
>> that.  */
>>  
>>  static void
>>  convert_all_function_calls (struct nesting_info *root)
>> -{
>> +{
>>    do
>>      {
>>        if (root->inner)
>> @@ -1784,7 +1845,10 @@
>>        walk_function (convert_call_expr, root);
>>  
>>        /* If the function does not use a static chain, then remember 
>> that.  */
>> -      if (root->outer && !root->chain_decl && !root->chain_field)
>> +      if (root->outer && !root->chain_decl && !root->chain_field
>> +/* REMOVE ME: */
>> +          /* && !debug_static_links () */
>> +         )
>>      DECL_NO_STATIC_CHAIN (root->context) = 1;
>>        else
>>      gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>> @@ -1806,6 +1870,21 @@
>>    tree context = root->context;
>>    struct function *sf;
>>  
>> +/* REMOVEME: */
>> +  /* If this is a nested function and we are supporting debugging via
>> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
>> +     chain, even if the programmer's code doesn't use it. */
>> +  if (false && root->outer && debug_static_links () )
>> +    { tree static_chain_decl, temp, stmt;
>> +      /* This is a desperate attempt to get later code generation to
>> +         store the static link.  If it works, it'll be a miracle. */
>> +      static_chain_decl = get_chain_decl (root);
>> +      stmt = build_addr (static_chain_decl, root->context);
>> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), 
>> NULL);
>> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>> +      append_to_statement_list (stmt, &stmt_list);
>> +    }
>> +
>>    /* If we created a non-local frame type or decl, we need to lay them
>>       out at this time.  */
>>    if (root->frame_type)
>> @@ -1912,7 +1991,7 @@
>>       proper BIND_EXPR.  */
>>    if (root->new_local_var_chain)
>>      declare_vars (root->new_local_var_chain, DECL_SAVED_TREE 
>> (root->context),
>> -          false);
>> +          true);
>>    if (root->debug_var_chain)
>>      declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>            true);
>>
>>
>>     
> 


From rodney_bates at lcwb.coop  Thu May 27 01:20:38 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 18:20:38 -0500
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>
Message-ID: <4BFDACC6.6020600@lcwb.coop>

After the marker, a closure also has two pointers, one to executable code,
and one to an environment of nonlocal variables.  These will always have
to be aligned to whatever pointers require on the target.  So making the
marker smaller than a native pointer would then require padding the
closure to get the pointers aligned.  This uses as much space as just
keeping the marker word-sized.

And no, I don't think it makes any sense to (on a 64-bit target) start
a closure on an odd multiple of 4 bytes, just so you can make the marker
smaller while keeping the following pointers word-aligned.

Jay K wrote:
> A little bit of research done (just searching the web):
>  Mips, Alpha, PowerPC, HPPA, ARM, SPARC
> 
> 
> all appear to use a 32bit instruction
> presumably aligned but I couldn't confirm for all of them.
>   It seems likely that if the processor cares about data alignment, then code will be aligned the same.
> 
> 
> Looks like SH has 16bit instructions.
> 
> 
> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
> With IA64 the expected exception with size=64bits, count=2.
>   It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>   We can revisit at that time.
> And really size=64, count=1 might suffice.
> 
> I'm a little torn.
> A 64bit marker is more certain.
> Code has been this way forever.
> etc.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>> Subject: closure marker
>> Date: Wed, 26 May 2010 15:13:38 +0000
>>
>>
>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>> 64bit systems that care about alignment pay quite a penality imho.
>>
>>
>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>
>>
>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>
>>
>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>   Do they have 4 byte instructions, that are always 4 byte aligned?
>>
>>
>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>
>>
>> More general might be
>>   Target.ClosureElementSize  (bits)
>>   Target.ClosureElementCount
>>
>>
>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>> Whereas most others would have Target.ClosureElementSize  = 32, Target.ClosureElementSize  = 1.
>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>
>>
>>
>>   - Jay
>>
>>
>  		 	   		  


From jay.krell at cornell.edu  Thu May 27 01:27:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 23:27:11 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <4BFDA90A.3050105@lcwb.coop>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>, ,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>
Message-ID: <COL101-W555E980AF6D3E51F8224B6E6E90@phx.gbl>


Rodney, if it doesn't work at all, and hasn't been worked on in a while, it should probably be removed.
If it works sometimes, ok.
If it say if (false) or #if 0, then it can be removed.
 If enabling that code provides something that sometimes work, why don't we just enable it always?
 Does it sometimes crash or have other bad properties?
 
 
I'm not just removing stuff, I'm also merging with 4.5.
The more we have, the more there is to merge.
Anything to reduce that work, even if it isn't huge in the first place, is good.
 [hypocrisy by me here]
 Dead code bears increasing cost, as we merge with more versions.
 
 
As well, if we are ever to be a gcc "plugin", we can't have any diffs. 
  "gcc plugin" is a new 4.5 feature.
I'm not sure this is a goal or viable, granted.
 
 
 
I don't like waiting for m3gdb to build and it isn't supported on some platforms e.g. Darwin.
I do want to see my data, but I'm skeptical it should require much or any changes to the debugger.
Esp. given that the changes to the compiler are pretty small.
Partly this is leftover from when I used Cygwin more -- everything (involving fork) is slow there.
 
 
 
There is part of the code that doesn't appear to be just about debugging and doesn't merge obviously.
The code it is in has been changed a lot, to iterate over a different form of data.
That I need I think I need to understand.
It appears, I think, that every single function call in Modula-3 has its codegen altered.
 Not just through pointers.
 It appears that way, and that is also my read of the m3back code, though I haven't yet looked at the generated code to confirm...and all my stepping through code in the past..I never noticed.
 
 
 
> Only calling procedures through a procedure-typed _parameter_ is
> slowed down. Calling through a procedure-typed _variable_ is known,

 
 Why are parameters different than variables?
 Can't I store a parameter in a variable? Even a local one? 
 Maybe not, because that might have bad "lifetime" and bad "safety"?
 
 
 
 Isn't every call through a function pointer affected?
 
 
What ATL does, you would call a "trampoline", but it isn't stored on the stack.
They call VirtualAlloc() which among the read/write flags includes an executable flag.
  At least on newer versions of Windows.
Since VirtualAlloc is expensive, as well as VirtualAlloc allocating in 64K chunk and the trampolines being small, a cache is maintained, as well as a presumably a sub-allocator being employed.
 
 
(If you think about it, you realize that there has *always* been some way to do this -- the linker writes a file and that file is executable. It could be "temporary", need not ever hit the disk.)
 
 
 - Jay



----------------------------------------
> Date: Wed, 26 May 2010 18:04:42 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
>
>
> Jay K wrote:
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>
>>>
>>>
>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions,
>
> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>
>>
>> Right..for those that don't know..
>>
>>
>> There's no "good" efficient way to implement nested functions.
>> Our implementation is pretty "bad".
>> gcc's implementation is pretty "bad".
>
> I think this is far too critical. The inefficiencies you see are
> minor. Certainly no worse than the implementation of dispatching
> methods of objects, something the world is gaga about. And the
> inefficiencies I think you are worrying about only arise when
> you pass procedures as parameters.
>
>
>
>
>> They are different.
>>
>>
>> gcc (Tony mentions "trampoline"):
>> In particular, taking the address of a nested function
>> involves runtime code generation on the stack.
>> These days, running code on the stack is "difficult".
>> On some systems, you do mprotect() to make that part of the stack executable.
>> On other systems, you just can't do it (iPhone).
>> On older systems, no problem. It is simple and efficient.
>>
>
> Yes, that is one consequence of trampolines. There has to be a place
> to generate code at runtime that will be executable, and a way to
> memory-manage it.
>
>>
>> Modula-3:
>> Whenever we go to call a function pointer, we first see if it start with a 4 or 8 byte -1.
>> If so, it is our "closure" thingy, and the -1 is followed
>> I guess by an actual function pointer and a static link.
>> The static link is loaded wherever and the function called.
>>
>>
>> Other systems (see modern ATL on Windows) allocate executable
>> memory not on the stack. Not even regular heap is executable
>> generally any longer though, one need to VirtualAlloc or mmap or such.
>>
>>
>> This is a powerful mechanism in general, you can do stuff like
>> runtime "currying".
>>
>>
>> Pointers to nested Modula-3 function cannot be passed off
>> as function pointers to other languages.
>> But hey, at least we can write nested functions and pass
>> them off to ourselves. Interop with C would just be bonus?
>>
>
> But if we used trampolines instead of our form of closures, they
> could be. Or, more generally, if we used the same mechanism as
> "other languages", they could be.
>
>>
>> Calling function pointers in Modula-3 is slowed down
>> everywhere, in case the function pointer is nested.
>> I think.
>
> Only calling procedures through a procedure-typed _parameter_ is
> slowed down. Calling through a procedure-typed _variable_ is known,
> by language semantics, always to be to a top-level procedure, and
> is as fast as a C call to a non-nested function pointer.
> Note that, when calling a function pointer to a nested procedure,
> trampolines are surely about as fast as you can get.
>
>>
>>
>> -1 must be ensured to be invalid code.
>> Or we could make it a more visible part of porting.
>> You know -- it could be per-target and folks would have
>> to experiment with each target to find a good sequence,
>> that is cheap to detect and guaranteed invalid.
>> (ie: 0 might be better than -1!)
>>
>>
>> Could possibly replace the -1 with an actual function pointer
>> that is always called.
>> But then pointers to non-nested functions also wouldn't
>> interoperate with C.
>
> I don't understand what mechanism you are proposing here. Taken
> literally, it sounds like a trampoline to me, which would allow
> non-nested and nested function pointers to interoperate with C.
>
>>
>>
>> I think there's something more to the mechanisms than I realize.
>> The "static link" must survive calls out to non-nested functions
>> or somesuch.
>>
>>
>> Anyway, while I think our mechanism is pretty clearly flawed,
>> it seems to be slightly less bad than gcc's.
>>
>
> I'm not sure what you mean by flawed, but if you mean it doesn't
> correctly implement language semantics, that is not true. It works
> correctly. So do trampolines, although in C (for other reasons that
> are independent of what mechanism you use for function pointers),
> the semantics of the language have a big hole. As usual, C passes
> the buck by defining this as "undefined".
>
>>
>> Perhaps we should invest in what ATL does though and
>> dynamically allocate executable memory not on the stack?
>
> If there is a way to do this, then trampolines can be made to work.
> What does gcc do now on such targets?
>
>> Still, an "open" iPhone is probably better with the current scheme.
>> Most other systems should be ok either way.
>>
>>
>> I think there is a bit of 4.3=>4.5 that needs closer attention
>> and isn't obvious, this part:
>>
>> + case STATIC_CHAIN_EXPR:
>> + decl = TREE_OPERAND (t, 0);
>> + target_context = decl_function_context (decl);
>> + if (target_context)
>> + {
>> + if (info->context == target_context)
>> + {
>> + /* Make sure frame_decl gets created. */
>> + (void) get_frame_type (info);
>> + }
>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>> + }
>> + else
>> + *tp = null_pointer_node;
>> + break;
>> +
>>
>> - Jay
>>
>
> Jay, you have made it clear repeatedly that you only use gdb, and
> never m3gdb, so obviously, Modula-3-specific support is of no importance
> to you. That's OK, but please don't spoil the game for those of us
> who do care about it by ripping stuff out of the compiler that m3gdb
> needs. Even when it isn't fully working yet.
>
> 		 	   		  

From jay.krell at cornell.edu  Thu May 27 01:38:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 23:38:09 +0000
Subject: [M3devel] closure marker
In-Reply-To: <4BFDACC6.6020600@lcwb.coop>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>,
	<4BFDACC6.6020600@lcwb.coop>
Message-ID: <COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>


Rodney, It's not a data size optimization. It is a code size optimization.
Adding the padding is ok.
 
 
 
See Aligned_procedures use in.
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
 
PROCEDURE If_closure (proc: Val;  true, false: Label;  freq: Frequency) =
  VAR skip := Next_label ();  nope := skip;
  BEGIN
    IF (false # No_label) THEN  nope := false; END;
    IF NOT Target.Aligned_procedures THEN
      Push (proc);
      Force ();
      cg.loophole (Type.Addr, Target.Integer.cg_type);
      Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
      cg.and (Target.Integer.cg_type);
      cg.if_true (Target.Integer.cg_type, nope, Always - freq);
      SPop (1, "If_closure-unaligned");
    END;
    Push (proc);
    Boost_alignment (Target.Address.align);
    Force ();
    cg.load_nil ();
    cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
    Push (proc);
    Boost_alignment (Target.Integer.align);
    Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
    Push_int (M3RT.CL_marker_value);
    IF (true # No_label)
      THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
      ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
    END;
    Set_label (skip);
    SPop (2, "If_closure");
  END If_closure;
 
 
Aligned_procedures would become effectively always true.
Code would be reduced.
 
 
I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
 
 
 - Jay



----------------------------------------
> Date: Wed, 26 May 2010 18:20:38 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
> After the marker, a closure also has two pointers, one to executable code,
> and one to an environment of nonlocal variables. These will always have
> to be aligned to whatever pointers require on the target. So making the
> marker smaller than a native pointer would then require padding the
> closure to get the pointers aligned. This uses as much space as just
> keeping the marker word-sized.
>
> And no, I don't think it makes any sense to (on a 64-bit target) start
> a closure on an odd multiple of 4 bytes, just so you can make the marker
> smaller while keeping the following pointers word-aligned.
>
> Jay K wrote:
>> A little bit of research done (just searching the web):
>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>
>>
>> all appear to use a 32bit instruction
>> presumably aligned but I couldn't confirm for all of them.
>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>
>>
>> Looks like SH has 16bit instructions.
>>
>>
>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>> With IA64 the expected exception with size=64bits, count=2.
>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>> We can revisit at that time.
>> And really size=64, count=1 might suffice.
>>
>> I'm a little torn.
>> A 64bit marker is more certain.
>> Code has been this way forever.
>> etc.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>> Subject: closure marker
>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>
>>>
>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>> 64bit systems that care about alignment pay quite a penality imho.
>>>
>>>
>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>
>>>
>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>
>>>
>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>
>>>
>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>
>>>
>>> More general might be
>>> Target.ClosureElementSize (bits)
>>> Target.ClosureElementCount
>>>
>>>
>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>> 		 	   		  

From mika at async.async.caltech.edu  Thu May 27 02:11:33 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 26 May 2010 17:11:33 -0700
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W555E980AF6D3E51F8224B6E6E90@phx.gbl> 
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>, ,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>
	<COL101-W555E980AF6D3E51F8224B6E6E90@phx.gbl>
Message-ID: <20100527001133.7A5831A207D@async.async.caltech.edu>

Jay K writes:
...
>=20
> Why are parameters different than variables?
> Can't I store a parameter in a variable? Even a local one?=20
> Maybe not=2C because that might have bad "lifetime" and bad "safety"?
...

No you can't assign a procedure parameter that came from an inner
procedure to a variable.

In the below example, the activation record for A is already destroyed
when I call b().  It's still there in C.

TYPE P = PROCEDURE();

VAR a,b : P;

PROCEDURE A() =

  PROCEDURE B() = BEGIN END B;

  PROCEDURE C(p : P) = BEGIN p() END C;

  BEGIN
    C(B);   (* OK *)
    b := B; (* BAD! *)
  END A;

BEGIN
  a := A;
  a(); (* OK *)
  b(); (* ERROR *)
END.

The runtime does check for this.  It aborts at (* BAD! *)

  
    Mika


From hosking at cs.purdue.edu  Thu May 27 11:27:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 05:27:56 -0400
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>,
	<4BFDA293.9080503@lcwb.coop>
	<COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>
Message-ID: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>

Argh!!!!!
No!  We don't want to do work in the front-end to get rid of nesting.
It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.



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 26 May 2010, at 18:53, Jay K wrote:

> 
> Rodney, When you get back to it, can you just dig it out of history?
> 
> 
> I still think we should try to avoid gcc's nested function functionality.
> 
> 
> Where you use the static chain, not using the nested function functionality should
> "automatically" be debuggable -- "automatic" as in, once the work is done
> in the frontend to transform out nesting.
> 
> 
> "debuggable" as in, you could follow the links yourself in the debugger.
> The debugger need not search lexically nested functions that have function
> calls dividing them.
> 
> 
> ?
> 
> 
> There's stuff I still need to understand better -- particularly the affect of nested functions
> on non-nested functions. Is there *always* an extra parameter to *all* functions?
> It appears so.
> And I haven't figured out how to merge with 4.5 what I think achieves that.
> 
> 
> Maybe a good test of test cases here?
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> Date: Wed, 26 May 2010 17:37:07 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>> 
>> I left it in because it is a work in progress. I *really* want to get it to
>> work, and I don't what to have to reinvent what is already there when I get
>> to it. I use nested procedures extensively in certain situations, and good
>> debugger support of them is important to me. It all works fine on older code
>> generators than the gcc that added tree-nested.c.
>> 
>> Jay K wrote:
>>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>>> Does it work?
>>> Does it accomplish anything?
>>> Can I remove it and its calls?
>>> 
>>> /* Special-purpose function to write stabs for the static_chain_decl.
>>> So far, this is not working. m3gdb needs the place in the activation
>>> record where the SL is stored. Right now, the SL is not necessarily
>>> stored at all, but may just be kept in a register. DECL_RTL and
>>> DECL_INCOMING_RTL may both have register expressions. But stabs
>>> entries for register variables, of kind N_RSYM, are currently ignored
>>> by gdb in dbxread.c, and making it read them could create problems
>>> elsewhere, because there can be other variables for which both an
>>> N_RSYM and an N_LSYM stabs entry are created.
>>> */
>>> static int
>>> dbxout_static_chain_decl (tree decl)
>>> 
>>> It was added 19 months ago by:
>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>> 
>>> as well, do we need the #if 0 code added then?
>>> 
>>> - Jay
>>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu May 27 11:32:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 05:32:19 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W50960886C3E99F184DBA1CE6E90@phx.gbl>
References: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>,
	<88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>
	<COL101-W50960886C3E99F184DBA1CE6E90@phx.gbl>
Message-ID: <2329B0DA-0FA5-4C74-9C12-A0CDFE35BADE@cs.purdue.edu>



On 26 May 2010, at 18:56, Jay K wrote:

> 
>>> Nested functions should be transformed to not be nested. Imho.
> 
>> I don't understand this. Nested functions must be nested in the sense that
>> they have static chain information provided by gcc.
> 
> 
> 
> Can it be achieved by adding an extra parameter instead?

The compiler *does* (inside gcc) add an extra parameter.

> 
> 
>>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
>> What do you mean by this?
> 
> 
> 
> It looks like we inhibit optimization if -g is specified.
> Like we preserve unused static chains.
> This is has been discussed and I have to look at the code more..
> Generating debug information should not inhibit optimisation.

Generating debug information inhibits optimisations where sufficient state needs to be kept around to support symbolic debugging.  I don't think it inhibits optimisation in any way we care about.

> 
> 
> 
> - Jay
> 
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 26 May 2010 10:26:32 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>> 
>> On 26 May 2010, at 03:55, Jay K wrote:
>> 
>>> 
>>> I'm going to try to keep the code that seems to do anything, however:
>>> 
>>> 1) if (false &&
>>> 
>>> I plan to remove that.
>>> 
>>> 
>>> 2)
>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>> +/* REMOVE ME: */
>>> + /* && !debug_static_links () */
>>> + )
>>> 
>>> 
>>> I can't find where that would apply, and it is commented out anyway so I'll remove it.
>>> 
>>> 
>>> I'm open to arguments though. :)
>>> 
>>> dbxout.c
>>> +#if 0
>>> +/* Code copied from 1.4.2.2: */
>>> 
>>> 
>>> I can cheaply enough keep that...should we really though?
>>> 
>>> 
>>> I really think we can reduce our changes.
>>> Enough type information should be passed around so that regular gdb works. Imho.
>> 
>> Possibly, but M3 has a very different notion of type to C. Moreover, it is extremely valuable to have the M3 type ids there so that functionality can map back to the types in the M3 runtime system. It would be possible to implement much of the m3gdb debugging support by calling back into the language run-time passing the language type ids instead of relying on hand-crafted C in m3gdb. But I agree that more type information would be good, particularly for records.
>> 
>>> And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
>>> don't cause internal compiler errors. So that debug info might be generated on systems
>>> that don't support stabs though granted they are few and minor (hppa64-hpux).
>>> Nested functions should be transformed to not be nested. Imho.
>> 
>> I don't understand this. Nested functions must be nested in the sense that they have static chain information provided by gcc.
>> 
>>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
>> 
>> What do you mean by this?
>> 
>>> 
>>> 
>>> I realize the type information getting around is probably a lot of work.
>>> And it is needed in m3back also, and probably not shared work.
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Subject: m3cc static chain stuff
>>>> Date: Wed, 26 May 2010 06:05:25 +0000
>>>> 
>>>> 
>>>> Can any of this be removed?
>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>> generally a considered the responsibility of optimizers.
>>>> 
>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>> Maybe I'll try without.
>>>> 
>>>> 
>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>> 
>>>> 
>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3-util.c */
>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>> +
>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>> be adding fields as necessary.
>>>> 
>>>> We also build the DECL that represents this frame in the function. */
>>>> @@ -209,7 +224,8 @@
>>>> free (name);
>>>> 
>>>> info->frame_type = type;
>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>> + info->frame_decl
>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>> 
>>>> /* ??? Always make it addressable for now, since it is meant to
>>>> be pointed to by the static chain pointer. This pessimizes
>>>> @@ -218,6 +234,8 @@
>>>> reachable, but the true pessimization is to create the non-
>>>> local frame structure in the first place. */
>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (info->frame_decl) = 0;
>>>> }
>>>> return type;
>>>> }
>>>> @@ -290,6 +308,10 @@
>>>> return *slot;
>>>> }
>>>> 
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_var_name = "_static_link_var";
>>>> +
>>>> /* Build or return the variable that holds the static chain within
>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>> 
>>>> @@ -310,9 +332,14 @@
>>>> Note also that it's represented as a parameter. This is more
>>>> close to the truth, since the initial value does come from
>>>> the caller. */
>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>> + decl = build_decl
>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>> DECL_ARTIFICIAL (decl) = 1;
>>>> - DECL_IGNORED_P (decl) = 1;
>>>> +
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (decl) = 0;
>>>> +
>>>> TREE_USED (decl) = 1;
>>>> DECL_CONTEXT (decl) = info->context;
>>>> DECL_ARG_TYPE (decl) = type;
>>>> @@ -326,7 +353,11 @@
>>>> return decl;
>>>> }
>>>> 
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>> +
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>> multiple nesting levels. */
>>>> 
>>>> @@ -339,10 +370,12 @@
>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>> 
>>>> field = make_node (FIELD_DECL);
>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>> TREE_TYPE (field) = type;
>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>> + /* m3gdb should know about this field. */
>>>> + DECL_IGNORED_P (field) = 0;
>>>> 
>>>> insert_field_into_struct (get_frame_type (info), field);
>>>> 
>>>> @@ -465,7 +498,7 @@
>>>> return *slot;
>>>> }
>>>> 
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>> rtl middle-end as dynamic stack space is allocated. */
>>>> 
>>>> @@ -1620,6 +1653,9 @@
>>>> switch (TREE_CODE (t))
>>>> {
>>>> case ADDR_EXPR:
>>>> + if (TREE_STATIC (t))
>>>> + break;
>>>> +
>>>> /* Build
>>>> T.1 = &CHAIN->tramp;
>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>> @@ -1714,6 +1750,22 @@
>>>> }
>>>> break;
>>>> 
>>>> + case STATIC_CHAIN_EXPR:
>>>> + decl = TREE_OPERAND (t, 0);
>>>> + target_context = decl_function_context (decl);
>>>> + if (target_context)
>>>> + {
>>>> + if (info->context == target_context)
>>>> + {
>>>> + /* Make sure frame_decl gets created. */
>>>> + (void) get_frame_type (info);
>>>> + }
>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>> + }
>>>> + else
>>>> + *tp = null_pointer_node;
>>>> + break;
>>>> +
>>>> case RETURN_EXPR:
>>>> case GIMPLE_MODIFY_STMT:
>>>> case WITH_SIZE_EXPR:
>>>> @@ -1768,13 +1820,22 @@
>>>> return NULL_TREE;
>>>> }
>>>> 
>>>> +static bool
>>>> +debug_static_links (void)
>>>> +{ return
>>>> + write_symbols != NO_DEBUG
>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>> +
>>>> +} /* debug_static_links */
>>>> +
>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>> trampolines and call expressions. On the way back up, determine if
>>>> a nested function actually uses its static chain; if not, remember that. */
>>>> 
>>>> static void
>>>> convert_all_function_calls (struct nesting_info *root)
>>>> -{
>>>> +{
>>>> do
>>>> {
>>>> if (root->inner)
>>>> @@ -1784,7 +1845,10 @@
>>>> walk_function (convert_call_expr, root);
>>>> 
>>>> /* If the function does not use a static chain, then remember that. */
>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>> +/* REMOVE ME: */
>>>> + /* && !debug_static_links () */
>>>> + )
>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>> else
>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>> @@ -1806,6 +1870,21 @@
>>>> tree context = root->context;
>>>> struct function *sf;
>>>> 
>>>> +/* REMOVEME: */
>>>> + /* If this is a nested function and we are supporting debugging via
>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>> + chain, even if the programmer's code doesn't use it. */
>>>> + if (false && root->outer && debug_static_links () )
>>>> + { tree static_chain_decl, temp, stmt;
>>>> + /* This is a desperate attempt to get later code generation to
>>>> + store the static link. If it works, it'll be a miracle. */
>>>> + static_chain_decl = get_chain_decl (root);
>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>> + append_to_statement_list (stmt, &stmt_list);
>>>> + }
>>>> +
>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>> out at this time. */
>>>> if (root->frame_type)
>>>> @@ -1912,7 +1991,7 @@
>>>> proper BIND_EXPR. */
>>>> if (root->new_local_var_chain)
>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>> - false);
>>>> + true);
>>>> if (root->debug_var_chain)
>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>> true);
>>>> 
>>>> 
>>>> 
>>> 
>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu May 27 11:33:52 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 05:33:52 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <4BFDAB5A.6000304@lcwb.coop>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
	<4BFDAB5A.6000304@lcwb.coop>
Message-ID: <D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>

The trampoline mechanism is broken on many platforms because they disable executable stacks.  I strongly favour retaining the current mechanisms.

On 26 May 2010, at 19:14, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible.  The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
> 
> I don't follow the last part of this argument.  If we follow the first
> principle, we would just use trampolines, since they are the same
> mechanism the C compiler uses.  And the only place they are not possible
> are places where they won't work for C either (e.g., a target where there
> is no place to construct code at runtime and have it be executable).
> The mere fact that we "also build closures" is not a necessity, just
> the reflection of the design decision to use the closure mechanism
> instead of trampolines.
> 
> OTHO, despite all the positive things I have said here and in another post
> about trampolines, I don't favor using them, because they would make m3gdb
> support a lot more difficult.  m3gdb needs to be able to both read and
> construct closures/trampolines, whichever.  Closures are almost target-
> independent, except for the native word size, which is already easily
> available to m3gdb.  Trampolines are going to be different for every
> instruction set, and the ones constructed by compiled code, at least,
> could even change with compiler version.  m3gdb would need a _lot_ of
> highly target-dependent code to handle them.
> 
>> 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 26 May 2010, at 02:05, Jay K wrote:
>>> 
>>> Can any of this be removed?
>>> Can we really not just use "unfold-nested-procs" like NT386?
>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>> generally a considered the responsibility of optimizers.
>>> 
>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>> Maybe I'll try without.
>>> 
>>> 
>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
>>> 
>>> 
>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>> -   shared between INFO->CONTEXT and its nested functions.  This record will
>>> -   not be complete until finalize_nesting_tree; up until that point we'll
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> +   m3-util.c */
>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>> +
>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>> +   that is shared between INFO->CONTEXT and its nested functions.  This record
>>> +   will not be complete until finalize_nesting_tree; up until that point we'll
>>>    be adding fields as necessary.
>>>     We also build the DECL that represents this frame in the function.  */
>>> @@ -209,7 +224,8 @@
>>>       free (name);
>>>        info->frame_type = type;
>>> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>> +      info->frame_decl
>>> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>        /* ??? Always make it addressable for now, since it is meant to
>>>      be pointed to by the static chain pointer.  This pessimizes
>>> @@ -218,6 +234,8 @@
>>>      reachable, but the true pessimization is to create the non-
>>>      local frame structure in the first place.  */
>>>       TREE_ADDRESSABLE (info->frame_decl) = 1;
>>> +      /* m3gdb needs to know about this variable. */
>>> +      DECL_IGNORED_P (info->frame_decl) = 0;      }
>>>   return type;
>>> }
>>> @@ -290,6 +308,10 @@
>>>   return *slot;
>>> }
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> +   m3_util.c */
>>> +static const char * static_link_var_name = "_static_link_var";
>>> +
>>> /* Build or return the variable that holds the static chain within
>>>    INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>>> @@ -310,9 +332,14 @@
>>>      Note also that it's represented as a parameter.  This is more
>>>      close to the truth, since the initial value does come from
>>>      the caller.  */
>>> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>> +      decl = build_decl
>>> +               (PARM_DECL, get_identifier (static_link_var_name), type);
>>> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>       DECL_ARTIFICIAL (decl) = 1;
>>> -      DECL_IGNORED_P (decl) = 1;
>>> +
>>> +      /* m3gdb needs to know about this variable. */
>>> +      DECL_IGNORED_P (decl) = 0;
>>> +
>>>       TREE_USED (decl) = 1;
>>>       DECL_CONTEXT (decl) = info->context;
>>>       DECL_ARG_TYPE (decl) = type;
>>> @@ -326,7 +353,11 @@
>>>   return decl;
>>> }
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> +   m3_util.c */
>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>> +
>>> +/* Build or return the field within the non-local frame struct that holds
>>>    the static chain for INFO->CONTEXT.  This is the way to walk back up
>>>    multiple nesting levels.  */
>>> @@ -339,10 +370,12 @@
>>>       tree type = build_pointer_type (get_frame_type (info->outer));
>>>        field = make_node (FIELD_DECL);
>>> -      DECL_NAME (field) = get_identifier ("__chain");
>>> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>       TREE_TYPE (field) = type;
>>>       DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>       DECL_NONADDRESSABLE_P (field) = 1;
>>> +      /* m3gdb should know about this field. */
>>> +      DECL_IGNORED_P (field) = 0;         insert_field_into_struct (get_frame_type (info), field);
>>> @@ -465,7 +498,7 @@
>>>   return *slot;
>>> }
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* Build or return the field within the non-local frame struct that holds
>>>    the non-local goto "jmp_buf".  The buffer itself is maintained by the
>>>    rtl middle-end as dynamic stack space is allocated.  */
>>> @@ -1620,6 +1653,9 @@
>>>   switch (TREE_CODE (t))
>>>     {
>>>     case ADDR_EXPR:
>>> +      if (TREE_STATIC (t))
>>> +    break;
>>> +
>>>       /* Build
>>>        T.1 = &CHAIN->tramp;
>>>        T.2 = __builtin_adjust_trampoline (T.1);
>>> @@ -1714,6 +1750,22 @@
>>>     }
>>>       break;
>>> +    case STATIC_CHAIN_EXPR:
>>> +      decl = TREE_OPERAND (t, 0);
>>> +      target_context = decl_function_context (decl);
>>> +      if (target_context)
>>> +    {
>>> +      if (info->context == target_context)
>>> +        {
>>> +          /* Make sure frame_decl gets created.  */
>>> +          (void) get_frame_type (info);
>>> +        }
>>> +      *tp = get_static_chain (info, target_context, &wi->tsi);
>>> +    }
>>> +      else
>>> +    *tp = null_pointer_node;
>>> +      break;
>>> +
>>>     case RETURN_EXPR:
>>>     case GIMPLE_MODIFY_STMT:
>>>     case WITH_SIZE_EXPR:
>>> @@ -1768,13 +1820,22 @@
>>>   return NULL_TREE;
>>> }
>>> +static bool
>>> +debug_static_links (void)
>>> +{ return
>>> +    write_symbols != NO_DEBUG
>>> +    && debug_info_level != DINFO_LEVEL_NONE
>>> +    && debug_info_level != DINFO_LEVEL_TERSE;
>>> +
>>> +} /* debug_static_links */
>>> +
>>> /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>>>    trampolines and call expressions.  On the way back up, determine if
>>>    a nested function actually uses its static chain; if not, remember that.  */
>>>  static void
>>> convert_all_function_calls (struct nesting_info *root)
>>> -{
>>> +{
>>>   do
>>>     {
>>>       if (root->inner)
>>> @@ -1784,7 +1845,10 @@
>>>       walk_function (convert_call_expr, root);
>>>        /* If the function does not use a static chain, then remember that.  */
>>> -      if (root->outer && !root->chain_decl && !root->chain_field)
>>> +      if (root->outer && !root->chain_decl && !root->chain_field
>>> +/* REMOVE ME: */
>>> +          /* && !debug_static_links () */
>>> +         )
>>>     DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>       else
>>>     gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>> @@ -1806,6 +1870,21 @@
>>>   tree context = root->context;
>>>   struct function *sf;
>>> +/* REMOVEME: */
>>> +  /* If this is a nested function and we are supporting debugging via
>>> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
>>> +     chain, even if the programmer's code doesn't use it. */
>>> +  if (false && root->outer && debug_static_links () )
>>> +    { tree static_chain_decl, temp, stmt;
>>> +      /* This is a desperate attempt to get later code generation to
>>> +         store the static link.  If it works, it'll be a miracle. */
>>> +      static_chain_decl = get_chain_decl (root);
>>> +      stmt = build_addr (static_chain_decl, root->context);
>>> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>> +      append_to_statement_list (stmt, &stmt_list);
>>> +    }
>>> +
>>>   /* If we created a non-local frame type or decl, we need to lay them
>>>      out at this time.  */
>>>   if (root->frame_type)
>>> @@ -1912,7 +1991,7 @@
>>>      proper BIND_EXPR.  */
>>>   if (root->new_local_var_chain)
>>>     declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>> -          false);
>>> +          true);
>>>   if (root->debug_var_chain)
>>>     declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>           true);
>>> 
>>> 
>>>    



From jay.krell at cornell.edu  Thu May 27 13:27:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 11:27:44 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
Message-ID: <col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>


I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
 
 
I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
  Because it has a similar but inferior mechanism.
 
 
One wonders about Ada though -- does it supported nested functions?
  I noticed it bears a striking resembles to Pascal/Modula-3. :)
 
And uses the same not great trampoline mechanism?
 
 
If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
Those are two very big ifs.
 
 
Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?
Ah.
We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
 
                             -- pointer to function --
                             -- parameter/static chain whatever --
 trampoline points here =>   -- start of code --
                             -- target dependent position independent not very optimized
                             -- *constant* hand crafted code that fetchs the data from just before itself
 
 
Would that address the m3gdb problem?
 Putting the data at fixed negative offsets from the trampoline code?
 Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
  to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
 
 
Granted, crafting that code would be.. fun. :)
Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 05:33:52 -0400
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>
> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>
>>
>>
>> Tony Hosking wrote:
>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>
>> I don't follow the last part of this argument. If we follow the first
>> principle, we would just use trampolines, since they are the same
>> mechanism the C compiler uses. And the only place they are not possible
>> are places where they won't work for C either (e.g., a target where there
>> is no place to construct code at runtime and have it be executable).
>> The mere fact that we "also build closures" is not a necessity, just
>> the reflection of the design decision to use the closure mechanism
>> instead of trampolines.
>>
>> OTHO, despite all the positive things I have said here and in another post
>> about trampolines, I don't favor using them, because they would make m3gdb
>> support a lot more difficult. m3gdb needs to be able to both read and
>> construct closures/trampolines, whichever. Closures are almost target-
>> independent, except for the native word size, which is already easily
>> available to m3gdb. Trampolines are going to be different for every
>> instruction set, and the ones constructed by compiled code, at least,
>> could even change with compiler version. m3gdb would need a _lot_ of
>> highly target-dependent code to handle them.
>>
>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>
>>>> Can any of this be removed?
>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>> generally a considered the responsibility of optimizers.
>>>>
>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>> Maybe I'll try without.
>>>>
>>>>
>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>
>>>>
>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3-util.c */
>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>> +
>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>> be adding fields as necessary.
>>>> We also build the DECL that represents this frame in the function. */
>>>> @@ -209,7 +224,8 @@
>>>> free (name);
>>>> info->frame_type = type;
>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>> + info->frame_decl
>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>> /* ??? Always make it addressable for now, since it is meant to
>>>> be pointed to by the static chain pointer. This pessimizes
>>>> @@ -218,6 +234,8 @@
>>>> reachable, but the true pessimization is to create the non-
>>>> local frame structure in the first place. */
>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>> return type;
>>>> }
>>>> @@ -290,6 +308,10 @@
>>>> return *slot;
>>>> }
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_var_name = "_static_link_var";
>>>> +
>>>> /* Build or return the variable that holds the static chain within
>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>> @@ -310,9 +332,14 @@
>>>> Note also that it's represented as a parameter. This is more
>>>> close to the truth, since the initial value does come from
>>>> the caller. */
>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>> + decl = build_decl
>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>> DECL_ARTIFICIAL (decl) = 1;
>>>> - DECL_IGNORED_P (decl) = 1;
>>>> +
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (decl) = 0;
>>>> +
>>>> TREE_USED (decl) = 1;
>>>> DECL_CONTEXT (decl) = info->context;
>>>> DECL_ARG_TYPE (decl) = type;
>>>> @@ -326,7 +353,11 @@
>>>> return decl;
>>>> }
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>> +
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>> multiple nesting levels. */
>>>> @@ -339,10 +370,12 @@
>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>> field = make_node (FIELD_DECL);
>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>> TREE_TYPE (field) = type;
>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>> + /* m3gdb should know about this field. */
>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>> @@ -465,7 +498,7 @@
>>>> return *slot;
>>>> }
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>> rtl middle-end as dynamic stack space is allocated. */
>>>> @@ -1620,6 +1653,9 @@
>>>> switch (TREE_CODE (t))
>>>> {
>>>> case ADDR_EXPR:
>>>> + if (TREE_STATIC (t))
>>>> + break;
>>>> +
>>>> /* Build
>>>> T.1 = &CHAIN->tramp;
>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>> @@ -1714,6 +1750,22 @@
>>>> }
>>>> break;
>>>> + case STATIC_CHAIN_EXPR:
>>>> + decl = TREE_OPERAND (t, 0);
>>>> + target_context = decl_function_context (decl);
>>>> + if (target_context)
>>>> + {
>>>> + if (info->context == target_context)
>>>> + {
>>>> + /* Make sure frame_decl gets created. */
>>>> + (void) get_frame_type (info);
>>>> + }
>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>> + }
>>>> + else
>>>> + *tp = null_pointer_node;
>>>> + break;
>>>> +
>>>> case RETURN_EXPR:
>>>> case GIMPLE_MODIFY_STMT:
>>>> case WITH_SIZE_EXPR:
>>>> @@ -1768,13 +1820,22 @@
>>>> return NULL_TREE;
>>>> }
>>>> +static bool
>>>> +debug_static_links (void)
>>>> +{ return
>>>> + write_symbols != NO_DEBUG
>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>> +
>>>> +} /* debug_static_links */
>>>> +
>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>> trampolines and call expressions. On the way back up, determine if
>>>> a nested function actually uses its static chain; if not, remember that. */
>>>> static void
>>>> convert_all_function_calls (struct nesting_info *root)
>>>> -{
>>>> +{
>>>> do
>>>> {
>>>> if (root->inner)
>>>> @@ -1784,7 +1845,10 @@
>>>> walk_function (convert_call_expr, root);
>>>> /* If the function does not use a static chain, then remember that. */
>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>> +/* REMOVE ME: */
>>>> + /* && !debug_static_links () */
>>>> + )
>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>> else
>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>> @@ -1806,6 +1870,21 @@
>>>> tree context = root->context;
>>>> struct function *sf;
>>>> +/* REMOVEME: */
>>>> + /* If this is a nested function and we are supporting debugging via
>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>> + chain, even if the programmer's code doesn't use it. */
>>>> + if (false && root->outer && debug_static_links () )
>>>> + { tree static_chain_decl, temp, stmt;
>>>> + /* This is a desperate attempt to get later code generation to
>>>> + store the static link. If it works, it'll be a miracle. */
>>>> + static_chain_decl = get_chain_decl (root);
>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>> + append_to_statement_list (stmt, &stmt_list);
>>>> + }
>>>> +
>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>> out at this time. */
>>>> if (root->frame_type)
>>>> @@ -1912,7 +1991,7 @@
>>>> proper BIND_EXPR. */
>>>> if (root->new_local_var_chain)
>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>> - false);
>>>> + true);
>>>> if (root->debug_var_chain)
>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>> true);
>>>>
>>>>
>>>>
> 		 	   		  

From jay.krell at cornell.edu  Thu May 27 13:31:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 11:31:20 +0000
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>, ,
	<4BFDA293.9080503@lcwb.coop>,
	<COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>,
	<665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
Message-ID: <COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>


Shouldn't gcc be able to optimize about as well any such transform?
  Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
 
Anyway, ok.
 
There's stuff I have to figure out and understand here either way.
 
Like, does the the static chain "flow" through non-nested calls?
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 05:27:56 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
>
>
> Argh!!!!!
> No! We don't want to do work in the front-end to get rid of nesting.
> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>
>
>
>
> 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 26 May 2010, at 18:53, Jay K wrote:
>
>
> Rodney, When you get back to it, can you just dig it out of history?
>
>
> I still think we should try to avoid gcc's nested function functionality.
>
>
> Where you use the static chain, not using the nested function functionality should
> "automatically" be debuggable -- "automatic" as in, once the work is done
> in the frontend to transform out nesting.
>
>
> "debuggable" as in, you could follow the links yourself in the debugger.
> The debugger need not search lexically nested functions that have function
> calls dividing them.
>
>
> ?
>
>
> There's stuff I still need to understand better -- particularly the affect of nested functions
> on non-nested functions. Is there *always* an extra parameter to *all* functions?
> It appears so.
> And I haven't figured out how to merge with 4.5 what I think achieves that.
>
>
> Maybe a good test of test cases here?
>
>
>
> - Jay
>
>
> ----------------------------------------
> Date: Wed, 26 May 2010 17:37:07 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
> I left it in because it is a work in progress. I *really* want to get it to
> work, and I don't what to have to reinvent what is already there when I get
> to it. I use nested procedures extensively in certain situations, and good
> debugger support of them is important to me. It all works fine on older code
> generators than the gcc that added tree-nested.c.
>
> Jay K wrote:
> Rodney, you added this function, along with a comment that says it doesn't actually work.
> Does it work?
> Does it accomplish anything?
> Can I remove it and its calls?
>
> /* Special-purpose function to write stabs for the static_chain_decl.
> So far, this is not working. m3gdb needs the place in the activation
> record where the SL is stored. Right now, the SL is not necessarily
> stored at all, but may just be kept in a register. DECL_RTL and
> DECL_INCOMING_RTL may both have register expressions. But stabs
> entries for register variables, of kind N_RSYM, are currently ignored
> by gdb in dbxread.c, and making it read them could create problems
> elsewhere, because there can be other variables for which both an
> N_RSYM and an N_LSYM stabs entry are created.
> */
> static int
> dbxout_static_chain_decl (tree decl)
>
> It was added 19 months ago by:
> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>
> as well, do we need the #if 0 code added then?
>
> - Jay
>
> 		 	   		  

From hosking at cs.purdue.edu  Thu May 27 14:10:50 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 08:10:50 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
	<col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
Message-ID: <BC008F6B-61C8-481A-9927-2B23DC6D6909@cs.purdue.edu>

m3gdb doesn't read trampolines because the gcc-based backend does not generate them!


On 27 May 2010, at 07:27, Jay K wrote:

> 
> I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
> 
> 
> I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
>  Because it has a similar but inferior mechanism.
> 
> 
> One wonders about Ada though -- does it supported nested functions?
>  I noticed it bears a striking resembles to Pascal/Modula-3. :)
> 
> And uses the same not great trampoline mechanism?
> 
> 
> If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
> Those are two very big ifs.
> 
> 
> Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?
> Ah.
> We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
> 
>                             -- pointer to function --
>                             -- parameter/static chain whatever --
> trampoline points here =>   -- start of code --
>                             -- target dependent position independent not very optimized
>                             -- *constant* hand crafted code that fetchs the data from just before itself
> 
> 
> Would that address the m3gdb problem?
> Putting the data at fixed negative offsets from the trampoline code?
> Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
>  to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
> 
> 
> Granted, crafting that code would be.. fun. :)
> Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:33:52 -0400
>> To: rodney_bates at lcwb.coop
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>> 
>> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>> 
>> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>> 
>>> 
>>> 
>>> Tony Hosking wrote:
>>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>> 
>>> I don't follow the last part of this argument. If we follow the first
>>> principle, we would just use trampolines, since they are the same
>>> mechanism the C compiler uses. And the only place they are not possible
>>> are places where they won't work for C either (e.g., a target where there
>>> is no place to construct code at runtime and have it be executable).
>>> The mere fact that we "also build closures" is not a necessity, just
>>> the reflection of the design decision to use the closure mechanism
>>> instead of trampolines.
>>> 
>>> OTHO, despite all the positive things I have said here and in another post
>>> about trampolines, I don't favor using them, because they would make m3gdb
>>> support a lot more difficult. m3gdb needs to be able to both read and
>>> construct closures/trampolines, whichever. Closures are almost target-
>>> independent, except for the native word size, which is already easily
>>> available to m3gdb. Trampolines are going to be different for every
>>> instruction set, and the ones constructed by compiled code, at least,
>>> could even change with compiler version. m3gdb would need a _lot_ of
>>> highly target-dependent code to handle them.
>>> 
>>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>> 
>>>>> Can any of this be removed?
>>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>>> generally a considered the responsibility of optimizers.
>>>>> 
>>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>>> Maybe I'll try without.
>>>>> 
>>>>> 
>>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>> 
>>>>> 
>>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3-util.c */
>>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>>> +
>>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>>> be adding fields as necessary.
>>>>> We also build the DECL that represents this frame in the function. */
>>>>> @@ -209,7 +224,8 @@
>>>>> free (name);
>>>>> info->frame_type = type;
>>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>>> + info->frame_decl
>>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>>> /* ??? Always make it addressable for now, since it is meant to
>>>>> be pointed to by the static chain pointer. This pessimizes
>>>>> @@ -218,6 +234,8 @@
>>>>> reachable, but the true pessimization is to create the non-
>>>>> local frame structure in the first place. */
>>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>>> return type;
>>>>> }
>>>>> @@ -290,6 +308,10 @@
>>>>> return *slot;
>>>>> }
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_var_name = "_static_link_var";
>>>>> +
>>>>> /* Build or return the variable that holds the static chain within
>>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>>> @@ -310,9 +332,14 @@
>>>>> Note also that it's represented as a parameter. This is more
>>>>> close to the truth, since the initial value does come from
>>>>> the caller. */
>>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>>> + decl = build_decl
>>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>>> DECL_ARTIFICIAL (decl) = 1;
>>>>> - DECL_IGNORED_P (decl) = 1;
>>>>> +
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (decl) = 0;
>>>>> +
>>>>> TREE_USED (decl) = 1;
>>>>> DECL_CONTEXT (decl) = info->context;
>>>>> DECL_ARG_TYPE (decl) = type;
>>>>> @@ -326,7 +353,11 @@
>>>>> return decl;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>>> +
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>>> multiple nesting levels. */
>>>>> @@ -339,10 +370,12 @@
>>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>>> field = make_node (FIELD_DECL);
>>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>>> TREE_TYPE (field) = type;
>>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>>> + /* m3gdb should know about this field. */
>>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>>> @@ -465,7 +498,7 @@
>>>>> return *slot;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>>> rtl middle-end as dynamic stack space is allocated. */
>>>>> @@ -1620,6 +1653,9 @@
>>>>> switch (TREE_CODE (t))
>>>>> {
>>>>> case ADDR_EXPR:
>>>>> + if (TREE_STATIC (t))
>>>>> + break;
>>>>> +
>>>>> /* Build
>>>>> T.1 = &CHAIN->tramp;
>>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>>> @@ -1714,6 +1750,22 @@
>>>>> }
>>>>> break;
>>>>> + case STATIC_CHAIN_EXPR:
>>>>> + decl = TREE_OPERAND (t, 0);
>>>>> + target_context = decl_function_context (decl);
>>>>> + if (target_context)
>>>>> + {
>>>>> + if (info->context == target_context)
>>>>> + {
>>>>> + /* Make sure frame_decl gets created. */
>>>>> + (void) get_frame_type (info);
>>>>> + }
>>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>>> + }
>>>>> + else
>>>>> + *tp = null_pointer_node;
>>>>> + break;
>>>>> +
>>>>> case RETURN_EXPR:
>>>>> case GIMPLE_MODIFY_STMT:
>>>>> case WITH_SIZE_EXPR:
>>>>> @@ -1768,13 +1820,22 @@
>>>>> return NULL_TREE;
>>>>> }
>>>>> +static bool
>>>>> +debug_static_links (void)
>>>>> +{ return
>>>>> + write_symbols != NO_DEBUG
>>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>>> +
>>>>> +} /* debug_static_links */
>>>>> +
>>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>>> trampolines and call expressions. On the way back up, determine if
>>>>> a nested function actually uses its static chain; if not, remember that. */
>>>>> static void
>>>>> convert_all_function_calls (struct nesting_info *root)
>>>>> -{
>>>>> +{
>>>>> do
>>>>> {
>>>>> if (root->inner)
>>>>> @@ -1784,7 +1845,10 @@
>>>>> walk_function (convert_call_expr, root);
>>>>> /* If the function does not use a static chain, then remember that. */
>>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>>> +/* REMOVE ME: */
>>>>> + /* && !debug_static_links () */
>>>>> + )
>>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>>> else
>>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>>> @@ -1806,6 +1870,21 @@
>>>>> tree context = root->context;
>>>>> struct function *sf;
>>>>> +/* REMOVEME: */
>>>>> + /* If this is a nested function and we are supporting debugging via
>>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>>> + chain, even if the programmer's code doesn't use it. */
>>>>> + if (false && root->outer && debug_static_links () )
>>>>> + { tree static_chain_decl, temp, stmt;
>>>>> + /* This is a desperate attempt to get later code generation to
>>>>> + store the static link. If it works, it'll be a miracle. */
>>>>> + static_chain_decl = get_chain_decl (root);
>>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>>> + append_to_statement_list (stmt, &stmt_list);
>>>>> + }
>>>>> +
>>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>>> out at this time. */
>>>>> if (root->frame_type)
>>>>> @@ -1912,7 +1991,7 @@
>>>>> proper BIND_EXPR. */
>>>>> if (root->new_local_var_chain)
>>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>>> - false);
>>>>> + true);
>>>>> if (root->debug_var_chain)
>>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>>> true);
>>>>> 
>>>>> 
>>>>> 
>> 		 	   		  



From jay.krell at cornell.edu  Thu May 27 14:26:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 12:26:18 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <BC008F6B-61C8-481A-9927-2B23DC6D6909@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
	<col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>,
	<BC008F6B-61C8-481A-9927-2B23DC6D6909@cs.purdue.edu>
Message-ID: <COL101-W509A5F179B6BE9A4C4CD1FE6EA0@phx.gbl>


But, it reads closures?
And IF there was a reasonable portable "executable heap", and trampolines were put there..the debugability could be solved as described -- putting the parameter(s) at fixed negative offsets from the code?

?- Jay


----------------------------------------
> Subject: Re: [M3devel] m3cc static chain stuff
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 08:10:50 -0400
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> m3gdb doesn't read trampolines because the gcc-based backend does not generate them!
>
>
> On 27 May 2010, at 07:27, Jay K wrote:
>
>>
>> I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
>>
>>
>> I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
>> Because it has a similar but inferior mechanism.
>>
>>
>> One wonders about Ada though -- does it supported nested functions?
>> I noticed it bears a striking resembles to Pascal/Modula-3. :)
>>
>> And uses the same not great trampoline mechanism?
>>
>>
>> If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
>> Those are two very big ifs.
>>
>>
>> Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?
>> Ah.
>> We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
>>
>> -- pointer to function --
>> -- parameter/static chain whatever --
>> trampoline points here => -- start of code --
>> -- target dependent position independent not very optimized
>> -- *constant* hand crafted code that fetchs the data from just before itself
>>
>>
>> Would that address the m3gdb problem?
>> Putting the data at fixed negative offsets from the trampoline code?
>> Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
>> to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
>>
>>
>> Granted, crafting that code would be.. fun. :)
>> Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 27 May 2010 05:33:52 -0400
>>> To: rodney_bates at lcwb.coop
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>
>>> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>>>
>>> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>>>
>>>>
>>>>
>>>> Tony Hosking wrote:
>>>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> I don't follow the last part of this argument. If we follow the first
>>>> principle, we would just use trampolines, since they are the same
>>>> mechanism the C compiler uses. And the only place they are not possible
>>>> are places where they won't work for C either (e.g., a target where there
>>>> is no place to construct code at runtime and have it be executable).
>>>> The mere fact that we "also build closures" is not a necessity, just
>>>> the reflection of the design decision to use the closure mechanism
>>>> instead of trampolines.
>>>>
>>>> OTHO, despite all the positive things I have said here and in another post
>>>> about trampolines, I don't favor using them, because they would make m3gdb
>>>> support a lot more difficult. m3gdb needs to be able to both read and
>>>> construct closures/trampolines, whichever. Closures are almost target-
>>>> independent, except for the native word size, which is already easily
>>>> available to m3gdb. Trampolines are going to be different for every
>>>> instruction set, and the ones constructed by compiled code, at least,
>>>> could even change with compiler version. m3gdb would need a _lot_ of
>>>> highly target-dependent code to handle them.
>>>>
>>>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>>>
>>>>>> Can any of this be removed?
>>>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>>>> generally a considered the responsibility of optimizers.
>>>>>>
>>>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>>>> Maybe I'll try without.
>>>>>>
>>>>>>
>>>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>>>
>>>>>>
>>>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>>> + m3-util.c */
>>>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>>>> +
>>>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>>>> be adding fields as necessary.
>>>>>> We also build the DECL that represents this frame in the function. */
>>>>>> @@ -209,7 +224,8 @@
>>>>>> free (name);
>>>>>> info->frame_type = type;
>>>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>>>> + info->frame_decl
>>>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>>>> /* ??? Always make it addressable for now, since it is meant to
>>>>>> be pointed to by the static chain pointer. This pessimizes
>>>>>> @@ -218,6 +234,8 @@
>>>>>> reachable, but the true pessimization is to create the non-
>>>>>> local frame structure in the first place. */
>>>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>>>> + /* m3gdb needs to know about this variable. */
>>>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>>>> return type;
>>>>>> }
>>>>>> @@ -290,6 +308,10 @@
>>>>>> return *slot;
>>>>>> }
>>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>>> + m3_util.c */
>>>>>> +static const char * static_link_var_name = "_static_link_var";
>>>>>> +
>>>>>> /* Build or return the variable that holds the static chain within
>>>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>>>> @@ -310,9 +332,14 @@
>>>>>> Note also that it's represented as a parameter. This is more
>>>>>> close to the truth, since the initial value does come from
>>>>>> the caller. */
>>>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>>>> + decl = build_decl
>>>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>>>> DECL_ARTIFICIAL (decl) = 1;
>>>>>> - DECL_IGNORED_P (decl) = 1;
>>>>>> +
>>>>>> + /* m3gdb needs to know about this variable. */
>>>>>> + DECL_IGNORED_P (decl) = 0;
>>>>>> +
>>>>>> TREE_USED (decl) = 1;
>>>>>> DECL_CONTEXT (decl) = info->context;
>>>>>> DECL_ARG_TYPE (decl) = type;
>>>>>> @@ -326,7 +353,11 @@
>>>>>> return decl;
>>>>>> }
>>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>>> + m3_util.c */
>>>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>>>> +
>>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>>>> multiple nesting levels. */
>>>>>> @@ -339,10 +370,12 @@
>>>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>>>> field = make_node (FIELD_DECL);
>>>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>>>> TREE_TYPE (field) = type;
>>>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>>>> + /* m3gdb should know about this field. */
>>>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>>>> @@ -465,7 +498,7 @@
>>>>>> return *slot;
>>>>>> }
>>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>>>> rtl middle-end as dynamic stack space is allocated. */
>>>>>> @@ -1620,6 +1653,9 @@
>>>>>> switch (TREE_CODE (t))
>>>>>> {
>>>>>> case ADDR_EXPR:
>>>>>> + if (TREE_STATIC (t))
>>>>>> + break;
>>>>>> +
>>>>>> /* Build
>>>>>> T.1 = &CHAIN->tramp;
>>>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>>>> @@ -1714,6 +1750,22 @@
>>>>>> }
>>>>>> break;
>>>>>> + case STATIC_CHAIN_EXPR:
>>>>>> + decl = TREE_OPERAND (t, 0);
>>>>>> + target_context = decl_function_context (decl);
>>>>>> + if (target_context)
>>>>>> + {
>>>>>> + if (info->context == target_context)
>>>>>> + {
>>>>>> + /* Make sure frame_decl gets created. */
>>>>>> + (void) get_frame_type (info);
>>>>>> + }
>>>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>>>> + }
>>>>>> + else
>>>>>> + *tp = null_pointer_node;
>>>>>> + break;
>>>>>> +
>>>>>> case RETURN_EXPR:
>>>>>> case GIMPLE_MODIFY_STMT:
>>>>>> case WITH_SIZE_EXPR:
>>>>>> @@ -1768,13 +1820,22 @@
>>>>>> return NULL_TREE;
>>>>>> }
>>>>>> +static bool
>>>>>> +debug_static_links (void)
>>>>>> +{ return
>>>>>> + write_symbols != NO_DEBUG
>>>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>>>> +
>>>>>> +} /* debug_static_links */
>>>>>> +
>>>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>>>> trampolines and call expressions. On the way back up, determine if
>>>>>> a nested function actually uses its static chain; if not, remember that. */
>>>>>> static void
>>>>>> convert_all_function_calls (struct nesting_info *root)
>>>>>> -{
>>>>>> +{
>>>>>> do
>>>>>> {
>>>>>> if (root->inner)
>>>>>> @@ -1784,7 +1845,10 @@
>>>>>> walk_function (convert_call_expr, root);
>>>>>> /* If the function does not use a static chain, then remember that. */
>>>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>>>> +/* REMOVE ME: */
>>>>>> + /* && !debug_static_links () */
>>>>>> + )
>>>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>>>> else
>>>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>>>> @@ -1806,6 +1870,21 @@
>>>>>> tree context = root->context;
>>>>>> struct function *sf;
>>>>>> +/* REMOVEME: */
>>>>>> + /* If this is a nested function and we are supporting debugging via
>>>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>>>> + chain, even if the programmer's code doesn't use it. */
>>>>>> + if (false && root->outer && debug_static_links () )
>>>>>> + { tree static_chain_decl, temp, stmt;
>>>>>> + /* This is a desperate attempt to get later code generation to
>>>>>> + store the static link. If it works, it'll be a miracle. */
>>>>>> + static_chain_decl = get_chain_decl (root);
>>>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>>>> + append_to_statement_list (stmt, &stmt_list);
>>>>>> + }
>>>>>> +
>>>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>>>> out at this time. */
>>>>>> if (root->frame_type)
>>>>>> @@ -1912,7 +1991,7 @@
>>>>>> proper BIND_EXPR. */
>>>>>> if (root->new_local_var_chain)
>>>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>>>> - false);
>>>>>> + true);
>>>>>> if (root->debug_var_chain)
>>>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>>>> true);
>>>>>>
>>>>>>
>>>>>>
>>>
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 27 14:54:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 12:54:39 +0000
Subject: [M3devel] a note on parse.c "GTY" use
Message-ID: <COL101-W792CCA7343DD604609EDCE6EA0@phx.gbl>


I am striving to have one parse.c be portable between gcc 4.5, gcc 4.2, and possibly gcc 4.3.
I already established 4.3/4.2 portability a year or so ago.


The main "indefinitely sticky" motivation is that Apple is only on 4.2 and they have a lot of changes.
? That I wouldn't want to merge.
We should imho, use their code for Darwin platforms, or at least Darwin/arm.
?? Mainline FSF seems to work fine for Darwin/ppc/x86 so I'm not advocating change there.



"indefinitely sticky" meaning, not really indefinite, but we aren't in control.
Presumably they'll move up to a newer version but I have no idea when.



Granted, Modula-3/iphone/pod/pad is seemingly nowhere.
A year or so ago I ran cm3 on my iPhone, got the usual "unable to find cm3.cfg", which is
exactly what you want to see when all you have is cm3 and no config files or source, and got distracted after that :)


An alternate motivation would be if we want to more easily move between 4.3 and 4.5.
This one we are more control of. If 4.5 has a few problems on a few platforms, we can
decide to debug and fix, or use 4.3 selectively.
I don't forsee problems major here though.


"Much ado about not much" -- more background than conclusion:


Gcc has some internal garbage collector. You have to annotate your code a bit for it.

In gcc 4.2/4.3 you say:

struct foo GTY()) { int field; } and such


In 4.5 you say:
struct  GTY()) foo { int field; } and such


The thing that scans your code I don't think knows much C.
I wasn't not able use #ifdef to guide it to varying versions.


Therefore, I've isolated 4.3 vs. 4.5-specific uses of GTY to their own files.
It's just a few lines.
But it is not how you would structure the code if not for this goal of working with multiple versions.


Generally otherwise I'll use #ifdef and have src/m3makefile #define whatever.
?Possibly prepending to parse.c, yucky, but oh well.
A read only source tree is ideal, granted, but I do what I can..


GTY is presumably "garbabe collected type" or such.



?- Jay
 		 	   		  

From jay.krell at cornell.edu  Thu May 27 15:07:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 13:07:10 +0000
Subject: [M3devel] a note on parse.c "GTY" use
In-Reply-To: <COL101-W792CCA7343DD604609EDCE6EA0@phx.gbl>
References: <COL101-W792CCA7343DD604609EDCE6EA0@phx.gbl>
Message-ID: <COL101-W3071349CB8D692DC65B62FE6EA0@phx.gbl>


Hm. Alternatively we could possibly use the data C types...

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 27 May 2010 12:54:39 +0000
> Subject: [M3devel] a note on parse.c "GTY" use
>
>
> I am striving to have one parse.c be portable between gcc 4.5, gcc 4.2, and possibly gcc 4.3.
> I already established 4.3/4.2 portability a year or so ago.
>
>
> The main "indefinitely sticky" motivation is that Apple is only on 4.2 and they have a lot of changes.
>   That I wouldn't want to merge.
> We should imho, use their code for Darwin platforms, or at least Darwin/arm.
>    Mainline FSF seems to work fine for Darwin/ppc/x86 so I'm not advocating change there.
>
>
>
> "indefinitely sticky" meaning, not really indefinite, but we aren't in control.
> Presumably they'll move up to a newer version but I have no idea when.
>
>
>
> Granted, Modula-3/iphone/pod/pad is seemingly nowhere.
> A year or so ago I ran cm3 on my iPhone, got the usual "unable to find cm3.cfg", which is
> exactly what you want to see when all you have is cm3 and no config files or source, and got distracted after that :)
>
>
> An alternate motivation would be if we want to more easily move between 4.3 and 4.5.
> This one we are more control of. If 4.5 has a few problems on a few platforms, we can
> decide to debug and fix, or use 4.3 selectively.
> I don't forsee problems major here though.
>
>
> "Much ado about not much" -- more background than conclusion:
>
>
> Gcc has some internal garbage collector. You have to annotate your code a bit for it.
>
> In gcc 4.2/4.3 you say:
>
> struct foo GTY()) { int field; } and such
>
>
> In 4.5 you say:
> struct GTY()) foo { int field; } and such
>
>
> The thing that scans your code I don't think knows much C.
> I wasn't not able use #ifdef to guide it to varying versions.
>
>
> Therefore, I've isolated 4.3 vs. 4.5-specific uses of GTY to their own files.
> It's just a few lines.
> But it is not how you would structure the code if not for this goal of working with multiple versions.
>
>
> Generally otherwise I'll use #ifdef and have src/m3makefile #define whatever.
>  Possibly prepending to parse.c, yucky, but oh well.
> A read only source tree is ideal, granted, but I do what I can..
>
>
> GTY is presumably "garbabe collected type" or such.
>
>
>
>  - Jay
>
 		 	   		  

From rodney_bates at lcwb.coop  Fri May 28 02:50:51 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 27 May 2010 19:50:51 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
	<col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
Message-ID: <4BFF136B.7020609@lcwb.coop>



Jay K wrote:
> I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
>  
>  
> I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
>   Because it has a similar but inferior mechanism.
>  
>  
> One wonders about Ada though -- does it supported nested functions?
>   I noticed it bears a striking resembles to Pascal/Modula-3. :)

Ada does have nested procedures, but it does not have variables or parameters
of procedure type at all, and it is these that need a closure/trampoline
mechanism, to hold a pointer to the "environment"  of the runtime procedure
value.

Actually, Ada has a form of procedure parameters, but they are
"generic" parameters, which means "instantiation" (i.e., supplying
the actual procedure parameter) is done statically.  This pretty
much always means the program unit with the procedure parameter
is copied at compile time and modified accordingly.

>  
> And uses the same not great trampoline mechanism?
>  
>  
> If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
> Those are two very big ifs.
>  
>  
> Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?

Yes,  The environment (address of the activation record) is in the closure.  If we used trampolines,
it would be in the trampoline instead.  m3gdb has to read these when an m3gdb expression contains
a call on a parameter of procedure type, to correctly execute the call.  It has to construct a
closure (or, again, it would be a trampoline, if we used them instead) to execute a call that
contains a nested procedure as an actual parameter.

> Ah.
> We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
>  
>                              -- pointer to function --
>                              -- parameter/static chain whatever --

                                   ^ For a single function, there can be many values of this.  Since this scheme
puts it right before the code of the nested procedure, there could only be one value of it.  Every different
parameter (to some other procedure, usually) can have a different environment.  So this won't work.

>  trampoline points here =>   -- start of code --
>                              -- target dependent position independent not very optimized
>                              -- *constant* hand crafted code that fetchs the data from just before itself
>  
>  
> Would that address the m3gdb problem?
>  Putting the data at fixed negative offsets from the trampoline code?
>  Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
>   to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
>  
>  
> Granted, crafting that code would be.. fun. :)
> Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
>  
>  
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:33:52 -0400
>> To: rodney_bates at lcwb.coop
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>>
>> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>>
>>>
>>> Tony Hosking wrote:
>>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>> I don't follow the last part of this argument. If we follow the first
>>> principle, we would just use trampolines, since they are the same
>>> mechanism the C compiler uses. And the only place they are not possible
>>> are places where they won't work for C either (e.g., a target where there
>>> is no place to construct code at runtime and have it be executable).
>>> The mere fact that we "also build closures" is not a necessity, just
>>> the reflection of the design decision to use the closure mechanism
>>> instead of trampolines.
>>>
>>> OTHO, despite all the positive things I have said here and in another post
>>> about trampolines, I don't favor using them, because they would make m3gdb
>>> support a lot more difficult. m3gdb needs to be able to both read and
>>> construct closures/trampolines, whichever. Closures are almost target-
>>> independent, except for the native word size, which is already easily
>>> available to m3gdb. Trampolines are going to be different for every
>>> instruction set, and the ones constructed by compiled code, at least,
>>> could even change with compiler version. m3gdb would need a _lot_ of
>>> highly target-dependent code to handle them.
>>>
>>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>> Can any of this be removed?
>>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>>> generally a considered the responsibility of optimizers.
>>>>>
>>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>>> Maybe I'll try without.
>>>>>
>>>>>
>>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>>
>>>>>
>>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3-util.c */
>>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>>> +
>>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>>> be adding fields as necessary.
>>>>> We also build the DECL that represents this frame in the function. */
>>>>> @@ -209,7 +224,8 @@
>>>>> free (name);
>>>>> info->frame_type = type;
>>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>>> + info->frame_decl
>>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>>> /* ??? Always make it addressable for now, since it is meant to
>>>>> be pointed to by the static chain pointer. This pessimizes
>>>>> @@ -218,6 +234,8 @@
>>>>> reachable, but the true pessimization is to create the non-
>>>>> local frame structure in the first place. */
>>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>>> return type;
>>>>> }
>>>>> @@ -290,6 +308,10 @@
>>>>> return *slot;
>>>>> }
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_var_name = "_static_link_var";
>>>>> +
>>>>> /* Build or return the variable that holds the static chain within
>>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>>> @@ -310,9 +332,14 @@
>>>>> Note also that it's represented as a parameter. This is more
>>>>> close to the truth, since the initial value does come from
>>>>> the caller. */
>>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>>> + decl = build_decl
>>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>>> DECL_ARTIFICIAL (decl) = 1;
>>>>> - DECL_IGNORED_P (decl) = 1;
>>>>> +
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (decl) = 0;
>>>>> +
>>>>> TREE_USED (decl) = 1;
>>>>> DECL_CONTEXT (decl) = info->context;
>>>>> DECL_ARG_TYPE (decl) = type;
>>>>> @@ -326,7 +353,11 @@
>>>>> return decl;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>>> +
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>>> multiple nesting levels. */
>>>>> @@ -339,10 +370,12 @@
>>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>>> field = make_node (FIELD_DECL);
>>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>>> TREE_TYPE (field) = type;
>>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>>> + /* m3gdb should know about this field. */
>>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>>> @@ -465,7 +498,7 @@
>>>>> return *slot;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>>> rtl middle-end as dynamic stack space is allocated. */
>>>>> @@ -1620,6 +1653,9 @@
>>>>> switch (TREE_CODE (t))
>>>>> {
>>>>> case ADDR_EXPR:
>>>>> + if (TREE_STATIC (t))
>>>>> + break;
>>>>> +
>>>>> /* Build
>>>>> T.1 = &CHAIN->tramp;
>>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>>> @@ -1714,6 +1750,22 @@
>>>>> }
>>>>> break;
>>>>> + case STATIC_CHAIN_EXPR:
>>>>> + decl = TREE_OPERAND (t, 0);
>>>>> + target_context = decl_function_context (decl);
>>>>> + if (target_context)
>>>>> + {
>>>>> + if (info->context == target_context)
>>>>> + {
>>>>> + /* Make sure frame_decl gets created. */
>>>>> + (void) get_frame_type (info);
>>>>> + }
>>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>>> + }
>>>>> + else
>>>>> + *tp = null_pointer_node;
>>>>> + break;
>>>>> +
>>>>> case RETURN_EXPR:
>>>>> case GIMPLE_MODIFY_STMT:
>>>>> case WITH_SIZE_EXPR:
>>>>> @@ -1768,13 +1820,22 @@
>>>>> return NULL_TREE;
>>>>> }
>>>>> +static bool
>>>>> +debug_static_links (void)
>>>>> +{ return
>>>>> + write_symbols != NO_DEBUG
>>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>>> +
>>>>> +} /* debug_static_links */
>>>>> +
>>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>>> trampolines and call expressions. On the way back up, determine if
>>>>> a nested function actually uses its static chain; if not, remember that. */
>>>>> static void
>>>>> convert_all_function_calls (struct nesting_info *root)
>>>>> -{
>>>>> +{
>>>>> do
>>>>> {
>>>>> if (root->inner)
>>>>> @@ -1784,7 +1845,10 @@
>>>>> walk_function (convert_call_expr, root);
>>>>> /* If the function does not use a static chain, then remember that. */
>>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>>> +/* REMOVE ME: */
>>>>> + /* && !debug_static_links () */
>>>>> + )
>>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>>> else
>>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>>> @@ -1806,6 +1870,21 @@
>>>>> tree context = root->context;
>>>>> struct function *sf;
>>>>> +/* REMOVEME: */
>>>>> + /* If this is a nested function and we are supporting debugging via
>>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>>> + chain, even if the programmer's code doesn't use it. */
>>>>> + if (false && root->outer && debug_static_links () )
>>>>> + { tree static_chain_decl, temp, stmt;
>>>>> + /* This is a desperate attempt to get later code generation to
>>>>> + store the static link. If it works, it'll be a miracle. */
>>>>> + static_chain_decl = get_chain_decl (root);
>>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>>> + append_to_statement_list (stmt, &stmt_list);
>>>>> + }
>>>>> +
>>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>>> out at this time. */
>>>>> if (root->frame_type)
>>>>> @@ -1912,7 +1991,7 @@
>>>>> proper BIND_EXPR. */
>>>>> if (root->new_local_var_chain)
>>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>>> - false);
>>>>> + true);
>>>>> if (root->debug_var_chain)
>>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>>> true);
>>>>>
>>>>>
>>>>>
>> 		 	   		  


From rodney_bates at lcwb.coop  Fri May 28 03:01:02 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 27 May 2010 20:01:02 -0500
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>, ,
	<4BFDA293.9080503@lcwb.coop>,
	<COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>,
	<665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
	<COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>
Message-ID: <4BFF15CE.7060908@lcwb.coop>



Jay K wrote:
> Shouldn't gcc be able to optimize about as well any such transform?
>   Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
>  
> Anyway, ok.
>  
> There's stuff I have to figure out and understand here either way.
>  
> Like, does the the static chain "flow" through non-nested calls?

The static chain flows through a series of activation records of calls
on progressively more shallowly nested procedures, until the last link
in the chain leads to an activation of a non-nested procedure.  Here the
static chain ends.

Conceptually, it would be convenient and consistent to think of this non-nested
procedure as having one more static link pointing to an area where all global
variables are stored, but in reality, almost no runtime addressing model does this.
Since globals have whole-program lifetime and always exactly one instance,
it is better to address them in some other way.

Note the static chain is needed for nested procedures even if there
are no procedure variables or parameters.  (e.g. Ada).

>  
>  - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:27:56 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>>
>>
>>
>> Argh!!!!!
>> No! We don't want to do work in the front-end to get rid of nesting.
>> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>>
>>
>>
>>
>> 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 26 May 2010, at 18:53, Jay K wrote:
>>
>>
>> Rodney, When you get back to it, can you just dig it out of history?
>>
>>
>> I still think we should try to avoid gcc's nested function functionality.
>>
>>
>> Where you use the static chain, not using the nested function functionality should
>> "automatically" be debuggable -- "automatic" as in, once the work is done
>> in the frontend to transform out nesting.
>>
>>
>> "debuggable" as in, you could follow the links yourself in the debugger.
>> The debugger need not search lexically nested functions that have function
>> calls dividing them.
>>
>>
>> ?
>>
>>
>> There's stuff I still need to understand better -- particularly the affect of nested functions
>> on non-nested functions. Is there *always* an extra parameter to *all* functions?
>> It appears so.
>> And I haven't figured out how to merge with 4.5 what I think achieves that.
>>
>>
>> Maybe a good test of test cases here?
>>
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>> Date: Wed, 26 May 2010 17:37:07 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>>
>> I left it in because it is a work in progress. I *really* want to get it to
>> work, and I don't what to have to reinvent what is already there when I get
>> to it. I use nested procedures extensively in certain situations, and good
>> debugger support of them is important to me. It all works fine on older code
>> generators than the gcc that added tree-nested.c.
>>
>> Jay K wrote:
>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>> Does it work?
>> Does it accomplish anything?
>> Can I remove it and its calls?
>>
>> /* Special-purpose function to write stabs for the static_chain_decl.
>> So far, this is not working. m3gdb needs the place in the activation
>> record where the SL is stored. Right now, the SL is not necessarily
>> stored at all, but may just be kept in a register. DECL_RTL and
>> DECL_INCOMING_RTL may both have register expressions. But stabs
>> entries for register variables, of kind N_RSYM, are currently ignored
>> by gdb in dbxread.c, and making it read them could create problems
>> elsewhere, because there can be other variables for which both an
>> N_RSYM and an N_LSYM stabs entry are created.
>> */
>> static int
>> dbxout_static_chain_decl (tree decl)
>>
>> It was added 19 months ago by:
>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>
>> as well, do we need the #if 0 code added then?
>>
>> - Jay
>>
>> 		 	   		  


From rodney_bates at lcwb.coop  Fri May 28 03:13:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 27 May 2010 20:13:46 -0500
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>,
	<4BFDACC6.6020600@lcwb.coop>
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>
Message-ID: <4BFF18CA.5070107@lcwb.coop>



Jay K wrote:
> Rodney, It's not a data size optimization. It is a code size optimization.
> Adding the padding is ok.
>  

I guess I am really confused here.  I thought you have been advocating making the
closure marker smaller than the native word size.  I don't see how this would
make closures that are not aligned be aligned.  Even if it did help with
the test of the closure marker, the fetching of the environment pointer and
code pointer would still have the same problem, and they can't be made shorter,
because they need all the bits for their values.

Any way, if you don't like the code that non-aligned closures require, why not
just choose to align them?  It seem so much easier than trying to micro-optimize
the code that solves an ugly problem.

>  
>  
> See Aligned_procedures use in.
> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
>  
> PROCEDURE If_closure (proc: Val;  true, false: Label;  freq: Frequency) =
>   VAR skip := Next_label ();  nope := skip;
>   BEGIN
>     IF (false # No_label) THEN  nope := false; END;
>     IF NOT Target.Aligned_procedures THEN
>       Push (proc);
>       Force ();
>       cg.loophole (Type.Addr, Target.Integer.cg_type);
>       Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
>       cg.and (Target.Integer.cg_type);
>       cg.if_true (Target.Integer.cg_type, nope, Always - freq);
>       SPop (1, "If_closure-unaligned");
>     END;
>     Push (proc);
>     Boost_alignment (Target.Address.align);
>     Force ();
>     cg.load_nil ();
>     cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
>     Push (proc);
>     Boost_alignment (Target.Integer.align);
>     Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
>     Push_int (M3RT.CL_marker_value);
>     IF (true # No_label)
>       THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
>       ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
>     END;
>     Set_label (skip);
>     SPop (2, "If_closure");
>   END If_closure;
>  
>  
> Aligned_procedures would become effectively always true.
> Code would be reduced.
>  
>  
> I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
>  
>  
>  - Jay
> 
> 
> 
> ----------------------------------------
>> Date: Wed, 26 May 2010 18:20:38 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] closure marker
>>
>> After the marker, a closure also has two pointers, one to executable code,
>> and one to an environment of nonlocal variables. These will always have
>> to be aligned to whatever pointers require on the target. So making the
>> marker smaller than a native pointer would then require padding the
>> closure to get the pointers aligned. This uses as much space as just
>> keeping the marker word-sized.
>>
>> And no, I don't think it makes any sense to (on a 64-bit target) start
>> a closure on an odd multiple of 4 bytes, just so you can make the marker
>> smaller while keeping the following pointers word-aligned.
>>
>> Jay K wrote:
>>> A little bit of research done (just searching the web):
>>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>>
>>>
>>> all appear to use a 32bit instruction
>>> presumably aligned but I couldn't confirm for all of them.
>>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>>
>>>
>>> Looks like SH has 16bit instructions.
>>>
>>>
>>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>>> With IA64 the expected exception with size=64bits, count=2.
>>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>>> We can revisit at that time.
>>> And really size=64, count=1 might suffice.
>>>
>>> I'm a little torn.
>>> A 64bit marker is more certain.
>>> Code has been this way forever.
>>> etc.
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>>> Subject: closure marker
>>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>>
>>>>
>>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>>> 64bit systems that care about alignment pay quite a penality imho.
>>>>
>>>>
>>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>>
>>>>
>>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>>
>>>>
>>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>>
>>>>
>>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>>
>>>>
>>>> More general might be
>>>> Target.ClosureElementSize (bits)
>>>> Target.ClosureElementCount
>>>>
>>>>
>>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>>
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>> 		 	   		  


From jay.krell at cornell.edu  Fri May 28 05:42:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 28 May 2010 03:42:09 +0000
Subject: [M3devel] closure marker
In-Reply-To: <4BFF18CA.5070107@lcwb.coop>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>, ,
	<4BFDACC6.6020600@lcwb.coop>,
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>,
	<4BFF18CA.5070107@lcwb.coop>
Message-ID: <COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>


What I'm describing is keep the closure the same -- integer -1, integer function pointer, integer chain.
But only read 4 bytes when checking for the -1.
Closures are always integer-aligned, but function pointers are not generally.
The code to check if it is a closure would just read 4 bytes and compare to -1, not check the alignment and then read integer-bytes.


Besides the micro-optimization, it *almost* eliminates target-specific code.
? Every time I ported to a system that cares about alignment I wasted time on this.
? Partly that was just because I didn't know about it. Now I know. Future ports easier.

The problem I think is that IA64 works neither with this scheme nor the existing scheme. Not sure.
? Seems more clear IA64 should have 128bit marker. But maybe 64bits are ok.
? If the bundle format is in the first 64 bits, not sure, and given that all bits 1 is an invalid bundle, then...
And possibly SH where code isn't necessarily 4-aligned. Not sure.

?- Jay

----------------------------------------
> Date: Thu, 27 May 2010 20:13:46 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
>
>
> Jay K wrote:
>> Rodney, It's not a data size optimization. It is a code size optimization.
>> Adding the padding is ok.
>>
>
> I guess I am really confused here. I thought you have been advocating making the
> closure marker smaller than the native word size. I don't see how this would
> make closures that are not aligned be aligned. Even if it did help with
> the test of the closure marker, the fetching of the environment pointer and
> code pointer would still have the same problem, and they can't be made shorter,
> because they need all the bits for their values.
>
> Any way, if you don't like the code that non-aligned closures require, why not
> just choose to align them? It seem so much easier than trying to micro-optimize
> the code that solves an ugly problem.
>
>>
>>
>> See Aligned_procedures use in.
>> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
>>
>> PROCEDURE If_closure (proc: Val; true, false: Label; freq: Frequency) =
>> VAR skip := Next_label (); nope := skip;
>> BEGIN
>> IF (false # No_label) THEN nope := false; END;
>> IF NOT Target.Aligned_procedures THEN
>> Push (proc);
>> Force ();
>> cg.loophole (Type.Addr, Target.Integer.cg_type);
>> Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
>> cg.and (Target.Integer.cg_type);
>> cg.if_true (Target.Integer.cg_type, nope, Always - freq);
>> SPop (1, "If_closure-unaligned");
>> END;
>> Push (proc);
>> Boost_alignment (Target.Address.align);
>> Force ();
>> cg.load_nil ();
>> cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
>> Push (proc);
>> Boost_alignment (Target.Integer.align);
>> Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
>> Push_int (M3RT.CL_marker_value);
>> IF (true # No_label)
>> THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
>> ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
>> END;
>> Set_label (skip);
>> SPop (2, "If_closure");
>> END If_closure;
>>
>>
>> Aligned_procedures would become effectively always true.
>> Code would be reduced.
>>
>>
>> I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
>>
>>
>> - Jay
>>
>>
>>
>> ----------------------------------------
>>> Date: Wed, 26 May 2010 18:20:38 -0500
>>> From: rodney_bates at lcwb.coop
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] closure marker
>>>
>>> After the marker, a closure also has two pointers, one to executable code,
>>> and one to an environment of nonlocal variables. These will always have
>>> to be aligned to whatever pointers require on the target. So making the
>>> marker smaller than a native pointer would then require padding the
>>> closure to get the pointers aligned. This uses as much space as just
>>> keeping the marker word-sized.
>>>
>>> And no, I don't think it makes any sense to (on a 64-bit target) start
>>> a closure on an odd multiple of 4 bytes, just so you can make the marker
>>> smaller while keeping the following pointers word-aligned.
>>>
>>> Jay K wrote:
>>>> A little bit of research done (just searching the web):
>>>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>>>
>>>>
>>>> all appear to use a 32bit instruction
>>>> presumably aligned but I couldn't confirm for all of them.
>>>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>>>
>>>>
>>>> Looks like SH has 16bit instructions.
>>>>
>>>>
>>>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>>>> With IA64 the expected exception with size=64bits, count=2.
>>>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>>>> We can revisit at that time.
>>>> And really size=64, count=1 might suffice.
>>>>
>>>> I'm a little torn.
>>>> A 64bit marker is more certain.
>>>> Code has been this way forever.
>>>> etc.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>>>> Subject: closure marker
>>>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>>>
>>>>>
>>>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>>>> 64bit systems that care about alignment pay quite a penality imho.
>>>>>
>>>>>
>>>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>>>
>>>>>
>>>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>>>
>>>>>
>>>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>>>
>>>>>
>>>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>>>
>>>>>
>>>>> More general might be
>>>>> Target.ClosureElementSize (bits)
>>>>> Target.ClosureElementCount
>>>>>
>>>>>
>>>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>
 		 	   		  

From hendrik at topoi.pooq.com  Sat May 29 00:04:01 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 28 May 2010 18:04:01 -0400
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <4BFF15CE.7060908@lcwb.coop>
References: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
	<COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>
	<4BFF15CE.7060908@lcwb.coop>
Message-ID: <20100528220400.GB4904@topoi.pooq.com>

On Thu, May 27, 2010 at 08:01:02PM -0500, Rodney M. Bates wrote:
>
>
> Jay K wrote:
>> Shouldn't gcc be able to optimize about as well any such transform?
>>   Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
>>  Anyway, ok.
>>  There's stuff I have to figure out and understand here either way.
>>  Like, does the the static chain "flow" through non-nested calls?
>
> The static chain flows through a series of activation records of calls
> on progressively more shallowly nested procedures, until the last link
> in the chain leads to an activation of a non-nested procedure.  Here the
> static chain ends.
>
> Conceptually, it would be convenient and consistent to think of this non-nested
> procedure as having one more static link pointing to an area where all global
> variables are stored, but in reality, almost no runtime addressing model does this.
> Since globals have whole-program lifetime and always exactly one instance,
> it is better to address them in some other way.
>
> Note the static chain is needed for nested procedures even if there
> are no procedure variables or parameters.  (e.g. Ada).

In Algol 68, when it's implemented using static links, the static chain 
doesn't thread *all* the chain of surrounding procedures -- it skips the 
ones that don't define any names used in the inner ones.

This bit of denesting might improve efficiency even in Modula 3, since 
some static chains might end up being shorter.  Whether it's worth the 
effort is another question, of course.

-- hendrik

>>> Argh!!!!!
>>> No! We don't want to do work in the front-end to get rid of nesting.
>>> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>>>
>>> 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


From hendrik at topoi.pooq.com  Sat May 29 00:07:20 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 28 May 2010 18:07:20 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <4BFDA90A.3050105@lcwb.coop>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>
	<4BFDA90A.3050105@lcwb.coop>
Message-ID: <20100528220720.GC4904@topoi.pooq.com>

On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>
>
> Jay K wrote:
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>
>>>
>>>
>>> We should endeavour to use the same functionality that the C compiler 
>>> uses for its own nested functions, 
>
> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>
>>
>> Right..for those that don't know..
>>
>>
>> There's no "good" efficient way to implement nested functions.
>> Our implementation is pretty "bad".
>> gcc's implementation is pretty "bad".
>
> I think this is far too critical.  The inefficiencies you see are
> minor.  Certainly no worse than the implementation of dispatching
> methods of objects, something the world is gaga about.

Sufficiently gaga that hardware manufacturers are trying to make it 
really fast.  Things like fetch- and branch- prediction.

We may as well use them if there isn't something better around.

-- hendrik


From jay.krell at cornell.edu  Sat May 29 05:10:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 29 May 2010 03:10:46 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <20100528220720.GC4904@topoi.pooq.com>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>,
	<20100528220720.GC4904@topoi.pooq.com>
Message-ID: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>


Ok ok let me explain my "real" questions.
 
 
 
 - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
 
 
 
and/or
 
 
 
 
 - Can someone show me how the above translates to C?
   Or Modula-3 with no nested functions.
   Using Modula-3 closures.
   It's not about the syntax, it's about a lower level model.
   Bonus points if you can show me the translation to C-like code with gcc trampolines also.
     That's mainly currently just for curiosity.
 
 
 
and/or
 
 
 
 - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
 
 
 
Like, I need to understand what to do for gcc 4.5.0.
 
 
Some of the tree-nested changes refer to a particular test case.
I'll look there to start.
 
 
 
In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
With a comment that maybe we could do it better.
The context in 4.5 is vastly different now.
The 4.3 changes "completely unmergable".
  I even looked around for somewhere else to put them.
 
 
 
Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
 Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
 
 
 
I'll see if I can get some clues here:
  http://gcc.gnu.org/onlinedocs/gccint/
 
 
:)
 
 
 - Jay




----------------------------------------
> Date: Fri, 28 May 2010 18:07:20 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>
>>
>> Jay K wrote:
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>
>>>>
>>>>
>>>> We should endeavour to use the same functionality that the C compiler
>>>> uses for its own nested functions,
>>
>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>
>>>
>>> Right..for those that don't know..
>>>
>>>
>>> There's no "good" efficient way to implement nested functions.
>>> Our implementation is pretty "bad".
>>> gcc's implementation is pretty "bad".
>>
>> I think this is far too critical. The inefficiencies you see are
>> minor. Certainly no worse than the implementation of dispatching
>> methods of objects, something the world is gaga about.
>
> Sufficiently gaga that hardware manufacturers are trying to make it
> really fast. Things like fetch- and branch- prediction.
>
> We may as well use them if there isn't something better around.
>
> -- hendrik 		 	   		  

From hendrik at topoi.pooq.com  Sat May 29 10:43:35 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 29 May 2010 04:43:35 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
References: <20100528220720.GC4904@topoi.pooq.com>
	<COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
Message-ID: <20100529084334.GA10658@topoi.pooq.com>

On Sat, May 29, 2010 at 03:10:46AM +0000, Jay K wrote:
> 
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  

Here's the classic test, in Algol 60:

begin
  real procedure A (k, x1, x2, x3, x4, x5);
  value k; integer k;
  begin
    real procedure B;
    begin k:= k - 1;
          B:= A := A (k, B, x1, x2, x3, x4);
    end;
    if k <= 0 then A:= x4 + x5 else B;
  end;
  outreal (A (10, 1, -1, -1, 1, 0));
end;

reference:

http://en.wikipedia.org/wiki/Man_or_boy_test

See also:

http://www.rosettacode.org/wiki/Man_or_boy_test

This page has a version which simulates closures in C.

-- hendrik


From rodney_bates at lcwb.coop  Sat May 29 22:03:58 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 29 May 2010 15:03:58 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>,
	<20100528220720.GC4904@topoi.pooq.com>
	<COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
Message-ID: <4C01732E.1070609@lcwb.coop>



Jay K wrote:
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  
>  
>  
> and/or
>  
>  
>  
>  
>  - Can someone show me how the above translates to C?
>    Or Modula-3 with no nested functions.
>    Using Modula-3 closures.
>    It's not about the syntax, it's about a lower level model.
>    Bonus points if you can show me the translation to C-like code with gcc trampolines also.
>      That's mainly currently just for curiosity.
>  
>  

I'm about to travel for a week, but maybe I'll give this a shot when I get back.
The problem is, it needs some diagrams, and I'm not fluent in any diagram
editor.  Maybe I can find/recommend a section of a good compiler book on this.

>  
> and/or
>  
>  
>  
>  - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
>  

I believe all that changes to tree-nested.c are mine, and they are only for debugging
support.  If the new tree-nested.c is very different, perhaps I should look at it.

>  
>  
> Like, I need to understand what to do for gcc 4.5.0.
>  
>  
> Some of the tree-nested changes refer to a particular test case.
> I'll look there to start.
>  
>  
>  
> In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
> With a comment that maybe we could do it better.
> The context in 4.5 is vastly different now.
> The 4.3 changes "completely unmergable".
>   I even looked around for somewhere else to put them.
>  
>  
>  
> Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
>  Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
>  
>  
>  
> I'll see if I can get some clues here:
>   http://gcc.gnu.org/onlinedocs/gccint/
>  
>  
> :)
>  
>  
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> Date: Fri, 28 May 2010 18:07:20 -0400
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>>
>>> Jay K wrote:
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>>
>>>>>
>>>>>
>>>>> We should endeavour to use the same functionality that the C compiler
>>>>> uses for its own nested functions,
>>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> Right..for those that don't know..
>>>>
>>>>
>>>> There's no "good" efficient way to implement nested functions.
>>>> Our implementation is pretty "bad".
>>>> gcc's implementation is pretty "bad".
>>> I think this is far too critical. The inefficiencies you see are
>>> minor. Certainly no worse than the implementation of dispatching
>>> methods of objects, something the world is gaga about.
>> Sufficiently gaga that hardware manufacturers are trying to make it
>> really fast. Things like fetch- and branch- prediction.
>>
>> We may as well use them if there isn't something better around.
>>
>> -- hendrik 		 	   		  


From rodney_bates at lcwb.coop  Sat May 29 22:26:11 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 29 May 2010 15:26:11 -0500
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>, ,
	<4BFDACC6.6020600@lcwb.coop>,
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>,
	<4BFF18CA.5070107@lcwb.coop>
	<COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>
Message-ID: <4C017863.2070209@lcwb.coop>

I might be starting to get the picture.  Here's what I think I understand so far:

On the target in question, native word is 64 bits.  Closures are three words, as
usual, all 64-bits and aligned to 64 bits.

The problem comes from the fact that, on this target, the first instruction of
the code of a procedure is not necessarily aligned to 64 bit.

So, when you have a parameter of procedure type, you can't immediately test
whether it points to a closure marker, because if not, it might be a code address
that is not a multiple of 8 bytes, and the attempt to test for the entire 64-bit
marker would suffer an alignment fault.

So, the generated code first tests whether it is a multiple of 8.  If not, that
means it points directly to code.  If so, it still could point to either code or
a closure, but now testing for the marker will not alignment-fault.  And it is
the first test you want to eliminate, right?

And your proposal is to code the marker test to only check a 32-bit half word
for all ones.  This will work for code addresses that are not multiples of 8,
but will still require them to be multiples of 4.

If Target.Aligned_procedures=FALSE really means they are not necessarily 8-byte aligned,
but are necessarily 4-byte aligned, which you need, then I think it is misnamed.
To me, and I think about anybody, I would expect Aligned_procedures=FALSE to mean
they are not aligned at all.  What does it actually mean, for various targets with
various native word sizes?

One approach would be to just make all first instructions of procedures be on
8-byte boundaries.   Aligned_procedures would be TRUE, and the extra code would
not be generated.  Actually, it is hard for me to imagine a modern object module
format and linker the did not ensure this, as I understand that usually, linkers
can selectively remove unreferenced procedures.  This would require the code of
every procedure to be in a separate "section" or whatever, which would then mean
it would be maximally aligned.

Another would be to ascertain that, in the targets where NOT Aligned_procedures,
a byte containing 16_FF can not be the first byte of any opcode.  If so, you
could just have the marker check test only one byte.  (But still build markers
the full length, just for consistency.)

Lacking any of the above, I'd just leave the extra code in there.

Jay K wrote:
> What I'm describing is keep the closure the same -- integer -1, integer function pointer, integer chain.
> But only read 4 bytes when checking for the -1.
> Closures are always integer-aligned, but function pointers are not generally.
> The code to check if it is a closure would just read 4 bytes and compare to -1, not check the alignment and then read integer-bytes.
> 
> 
> Besides the micro-optimization, it *almost* eliminates target-specific code.
>   Every time I ported to a system that cares about alignment I wasted time on this.
>   Partly that was just because I didn't know about it. Now I know. Future ports easier.
> 
> The problem I think is that IA64 works neither with this scheme nor the existing scheme. Not sure.
>   Seems more clear IA64 should have 128bit marker. But maybe 64bits are ok.
>   If the bundle format is in the first 64 bits, not sure, and given that all bits 1 is an invalid bundle, then...
> And possibly SH where code isn't necessarily 4-aligned. Not sure.
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Thu, 27 May 2010 20:13:46 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] closure marker
>>
>>
>>
>> Jay K wrote:
>>> Rodney, It's not a data size optimization. It is a code size optimization.
>>> Adding the padding is ok.
>>>
>> I guess I am really confused here. I thought you have been advocating making the
>> closure marker smaller than the native word size. I don't see how this would
>> make closures that are not aligned be aligned. Even if it did help with
>> the test of the closure marker, the fetching of the environment pointer and
>> code pointer would still have the same problem, and they can't be made shorter,
>> because they need all the bits for their values.
>>
>> Any way, if you don't like the code that non-aligned closures require, why not
>> just choose to align them? It seem so much easier than trying to micro-optimize
>> the code that solves an ugly problem.
>>
>>>
>>> See Aligned_procedures use in.
>>> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
>>>
>>> PROCEDURE If_closure (proc: Val; true, false: Label; freq: Frequency) =
>>> VAR skip := Next_label (); nope := skip;
>>> BEGIN
>>> IF (false # No_label) THEN nope := false; END;
>>> IF NOT Target.Aligned_procedures THEN
>>> Push (proc);
>>> Force ();
>>> cg.loophole (Type.Addr, Target.Integer.cg_type);
>>> Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
>>> cg.and (Target.Integer.cg_type);
>>> cg.if_true (Target.Integer.cg_type, nope, Always - freq);
>>> SPop (1, "If_closure-unaligned");
>>> END;
>>> Push (proc);
>>> Boost_alignment (Target.Address.align);
>>> Force ();
>>> cg.load_nil ();
>>> cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
>>> Push (proc);
>>> Boost_alignment (Target.Integer.align);
>>> Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
>>> Push_int (M3RT.CL_marker_value);
>>> IF (true # No_label)
>>> THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
>>> ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
>>> END;
>>> Set_label (skip);
>>> SPop (2, "If_closure");
>>> END If_closure;
>>>
>>>
>>> Aligned_procedures would become effectively always true.
>>> Code would be reduced.
>>>
>>>
>>> I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Date: Wed, 26 May 2010 18:20:38 -0500
>>>> From: rodney_bates at lcwb.coop
>>>> To: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] closure marker
>>>>
>>>> After the marker, a closure also has two pointers, one to executable code,
>>>> and one to an environment of nonlocal variables. These will always have
>>>> to be aligned to whatever pointers require on the target. So making the
>>>> marker smaller than a native pointer would then require padding the
>>>> closure to get the pointers aligned. This uses as much space as just
>>>> keeping the marker word-sized.
>>>>
>>>> And no, I don't think it makes any sense to (on a 64-bit target) start
>>>> a closure on an odd multiple of 4 bytes, just so you can make the marker
>>>> smaller while keeping the following pointers word-aligned.
>>>>
>>>> Jay K wrote:
>>>>> A little bit of research done (just searching the web):
>>>>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>>>>
>>>>>
>>>>> all appear to use a 32bit instruction
>>>>> presumably aligned but I couldn't confirm for all of them.
>>>>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>>>>
>>>>>
>>>>> Looks like SH has 16bit instructions.
>>>>>
>>>>>
>>>>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>>>>> With IA64 the expected exception with size=64bits, count=2.
>>>>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>>>>> We can revisit at that time.
>>>>> And really size=64, count=1 might suffice.
>>>>>
>>>>> I'm a little torn.
>>>>> A 64bit marker is more certain.
>>>>> Code has been this way forever.
>>>>> etc.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>>>>> Subject: closure marker
>>>>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>>>>
>>>>>>
>>>>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>>>>> 64bit systems that care about alignment pay quite a penality imho.
>>>>>>
>>>>>>
>>>>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>>>>
>>>>>>
>>>>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>>>>
>>>>>>
>>>>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>>>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>>>>
>>>>>>
>>>>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>>>>
>>>>>>
>>>>>> More general might be
>>>>>> Target.ClosureElementSize (bits)
>>>>>> Target.ClosureElementCount
>>>>>>
>>>>>>
>>>>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>>>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>>>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>  		 	   		  


From rodney_bates at lcwb.coop  Sat May 29 23:17:25 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 29 May 2010 16:17:25 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>,
	<20100528220720.GC4904@topoi.pooq.com>
	<COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
Message-ID: <4C018465.7000204@lcwb.coop>

More concerning tree-nested.c:

I am now remembering that there was some inconsistent terminology in
tree-nested.c, calling the same thing by different names, etc, in
comments, and, I think, in some identifiers too.  One thing I did
was clean this up, after having to unravel it for the second time,
not remembering it all from the first time.

If history is any guide, just moving to a newer base gcc will no
doubt break several things in m3gdb, and I'll probably be the logical
one to do most of that part of the patching.


Jay K wrote:
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  
>  
>  
> and/or
>  
>  
>  
>  
>  - Can someone show me how the above translates to C?
>    Or Modula-3 with no nested functions.
>    Using Modula-3 closures.
>    It's not about the syntax, it's about a lower level model.
>    Bonus points if you can show me the translation to C-like code with gcc trampolines also.
>      That's mainly currently just for curiosity.
>  
>  
>  
> and/or
>  
>  
>  
>  - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
>  
>  
>  
> Like, I need to understand what to do for gcc 4.5.0.
>  
>  
> Some of the tree-nested changes refer to a particular test case.
> I'll look there to start.
>  
>  
>  
> In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
> With a comment that maybe we could do it better.
> The context in 4.5 is vastly different now.
> The 4.3 changes "completely unmergable".
>   I even looked around for somewhere else to put them.
>  
>  
>  
> Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
>  Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
>  
>  
>  
> I'll see if I can get some clues here:
>   http://gcc.gnu.org/onlinedocs/gccint/
>  
>  
> :)
>  
>  
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> Date: Fri, 28 May 2010 18:07:20 -0400
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>>
>>> Jay K wrote:
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>>
>>>>>
>>>>>
>>>>> We should endeavour to use the same functionality that the C compiler
>>>>> uses for its own nested functions,
>>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> Right..for those that don't know..
>>>>
>>>>
>>>> There's no "good" efficient way to implement nested functions.
>>>> Our implementation is pretty "bad".
>>>> gcc's implementation is pretty "bad".
>>> I think this is far too critical. The inefficiencies you see are
>>> minor. Certainly no worse than the implementation of dispatching
>>> methods of objects, something the world is gaga about.
>> Sufficiently gaga that hardware manufacturers are trying to make it
>> really fast. Things like fetch- and branch- prediction.
>>
>> We may as well use them if there isn't something better around.
>>
>> -- hendrik 		 	   		  


From jay.krell at cornell.edu  Sun May 30 09:45:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 07:45:38 +0000
Subject: [M3devel] closure marker
In-Reply-To: <4C017863.2070209@lcwb.coop>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>,
	, , <4BFDACC6.6020600@lcwb.coop>, ,
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>, ,
	<4BFF18CA.5070107@lcwb.coop>,
	<COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>,
	<4C017863.2070209@lcwb.coop>
Message-ID: <COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>


> On the target in question, native word is 64 bits. Closures are three words, as
> usual, all 64-bits and aligned to 64 bits.

Right.
Though I think for IA64 we might need 128bit marker.
?At least that is the easy conclusion barring deeper understanding.


> The problem comes from the fact that, on this target, the first instruction of
> the code of a procedure is not necessarily aligned to 64 bit.


Right.


> So, when you have a parameter of procedure type, you can't immediately test
> whether it points to a closure marker, because if not, it might be a code address
> that is not a multiple of 8 bytes, and the attempt to test for the entire 64-bit
> marker would suffer an alignment fault.


Right.
I've seen these alignment faults doing several ports.
But now we all know, so maybe not a big deal.


> So, the generated code first tests whether it is a multiple of 8. If not, that
> means it points directly to code. If so, it still could point to either code or
> a closure, but now testing for the marker will not alignment-fault. And it is
> the first test you want to eliminate, right?


Right.


> And your proposal is to code the marker test to only check a 32-bit half word
> for all ones. This will work for code addresses that are not multiples of 8,
> but will still require them to be multiples of 4.


Right.
Admited, initially I forgot about the "rest" of the closure, so didn't
allow for the extra in what I said.


> If Target.Aligned_procedures=FALSE really means they are not necessarily 8-byte aligned,
> but are necessarily 4-byte aligned, which you need, then I think it is misnamed.
> To me, and I think about anybody, I would expect Aligned_procedures=FALSE to mean
> they are not aligned at all. What does it actually mean, for various targets with
> various native word sizes?


Right -- the name is wierd, but hard to come up with another.
It means: can an integer-sized read from a function pointer possibly generate an alignment exception.
Inverted.
For example. on all x86 and AMD64 targets, it is true. Because none of them ever generate
alignment faults (maybe for SSE stuff, irrelevant).


On most/all 32bit targets is also true, because instructions are often guaranteed 4 byte aligned.


?> One approach would be to just make all first instructions of procedures be on
?> 8-byte boundaries.


That might not be trivial.
C code matters too.
It can also be size-wasteful, but often speed-optimizing.


?> Aligned_procedures would be TRUE, and the extra code would
> not be generated. Actually, it is hard for me to imagine a modern object module
> format and linker the did not ensure this, as I understand that usually, linkers
> can selectively remove unreferenced procedures. This would require the code of
> every procedure to be in a separate "section" or whatever, which would then mean
> it would be maximally aligned.


All modern systems (can) remove unused functions.
Surprisingly I don't think this is always/often the default.
In Visual C++ you have to use the -Gy flag to the compiler.
But that doesn't imply anything about alignment.
Maybe you are confusing some concepts?
For example on Win32, executables have "sections".


e.g. .text, .data, .rdata.


By "conceptual reverse engineering", I claim that "sections" exist in order to apply
different page attributes to parts of code/data. That is, read only data and writable
data must be on different pages, if the read onliness is to actually exist and be hardware-enforced.


Therefore, whichever of the two, readonly/writable, comes second, must be page aligned,
in order to not be on the same page as the previous.


On modern systems that have a page attribute "executable", code must also be separate from
read only data.


This does *not* relate to any sort of alignment of functions (except maybe the first function
in an .exe/.dll, maybe).


Sections can also be a crude tool to influence layout and improve locality.
For example the data needed to handle exceptions might be in its own section, in order
to keep it "far away" from everything else, since it is rarely accessed.
Even though it generally just as well be part of read only data.
This way "everything else" is denser and fits on fewer pages.


Size and density are the generally dominant performance factors in most systems.
Touching the disk to page in stuff is among the slowest operations by far, so
reducing size, in order to reduce the number of pages touched, is important.
? Bigger code that is deemed "faster" is rarely preferred.
? Smaller code is also preferred in "embedded" systems.

Anyway..


> Another would be to ascertain that, in the targets where NOT Aligned_procedures,
> a byte containing 16_FF can not be the first byte of any opcode.
> If so, you? could just have the marker check test only one byte. (But still build markers
> the full length, just for consistency.)


No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
I'm not willing to make that bet.
Even the notion of 4 or 8 byte -1 I find tenuous.
You cannot portably/easily guarantee that such bytes aren't valid/existant code.
You must research all the various architecture encodings.
? Granted, we are only talking about function prologues..
The longer the sequence, the statistically less likely it is valid or existant code.
And there is a limit, per-architecture.
Many architectures have fixed length instructions.
On such architectures, going beyond that length does not change the odds of validity,
though does change the odds of existance (if valid). But our hope is really for invalidity,
not mere non-existance.


> Lacking any of the above, I'd just leave the extra code in there.


Yeah, it's not as much as I had thougt.
I was thinking it generated code to read the bytes piecemeal or something.


Again though, my real goal is to try to remove platform-specificity.
Something that can be made true for all architectures with no downside, should be made so,
and the variable removed.


I think even the current scheme maybe invalid for IA64.
We should probably have ClosureMarkerSizeStored and ClosureMarkerSizeChecked.
?


Except for IA64 and possibly SH, ClosureMarkerSizeStored should be sizeof(INTEGER) and ClosureMarkerSizeChecked would be 4.


The nice property there is that, barring existance of IA64 and SH, we would remove the target-specificity entirely,
and m3gdb would be unchanged. IA64 and SH might work, not sure.
I do have two IA64 machines and a Dreamcast, but...


I'd also like to understand what this all might look like with a portable C generating backend.
Clearly, reasonably the generated code might need to be able to say:
?#if WORD_SIZE == 4 
?#if ENDIAN == LITTLE_ENDIAN 


but hopefully not much else.
And maybe not even those. :)


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sun May 30 11:47:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 09:47:21 +0000
Subject: [M3devel] the slightly difficult to merge parts 4.3 vs. 4.5
Message-ID: <COL101-W641326A298A33186042008E6ED0@phx.gbl>


--- /src/orig/gcc-4.3.0/gcc/tree-gimple.c??? 2007-12-13 13:49:09.000000000 -0800
+++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-gimple.c??? 2010-05-09 22:27:56.000000000 -0700
@@ -74,6 +74,7 @@
???? case VECTOR_CST:
???? case OBJ_TYPE_REF:
???? case ASSERT_EXPR:
+??? case STATIC_CHAIN_EXPR:
?????? return true;
?
???? default:


That is in is gimple_formal_tmp_rhs, which no longer exists, but which the various
callers do. One obvious guess is callers should each check for STATIC_CHAIN_EXPR.



tree-nested.c:
+??? case STATIC_CHAIN_EXPR:
+????? decl = TREE_OPERAND (t, 0);
+????? target_context = decl_function_context (decl);
+????? if (target_context)
+??? {
+??? ? if (info->context == target_context)
+??? ??? {
+??? ????? /* Make sure frame_decl gets created.? */
+??? ????? (void) get_frame_type (info);
+??? ??? }
+??? ? *tp = get_static_chain (info, target_context, &wi->tsi);
+??? }
+????? else
+??? *tp = null_pointer_node;
+????? break;
+


That is in convert_call_expr.
Which is now called convert_gimple_call, but which is significantly different.
Hm..I see...there is a new gimple.def, similar to tree.def..

Maybe just have to put STATIC_CHAIN_EXPR in there instead, or
put a form in each.

?- Jay

 		 	   		  

From hendrik at topoi.pooq.com  Sun May 30 08:56:47 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 30 May 2010 02:56:47 -0400
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>
References: <4C017863.2070209@lcwb.coop>
	<COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>
Message-ID: <20100530065647.GA21438@topoi.pooq.com>

On Sun, May 30, 2010 at 07:45:38AM +0000, Jay K wrote:
> 
> > On the target in question, native word is 64 bits. Closures are three words, as
> > usual, all 64-bits and aligned to 64 bits.
> 
> Right.
> Though I think for IA64 we might need 128bit marker.
> ?At least that is the easy conclusion barring deeper understanding.
> 
...
...
> 
> 
> Size and density are the generally dominant performance factors in most systems.
> Touching the disk to page in stuff is among the slowest operations by far, so
> reducing size, in order to reduce the number of pages touched, is important.
> ? Bigger code that is deemed "faster" is rarely preferred.
> ? Smaller code is also preferred in "embedded" systems.
> 
...
...> 
> No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
> I'm not willing to make that bet.
> Even the notion of 4 or 8 byte -1 I find tenuous.
> You cannot portably/easily guarantee that such bytes aren't valid/existant code.
> You must research all the various architecture encodings.
> ? Granted, we are only talking about function prologues..
> The longer the sequence, the statistically less likely it is valid or existant code.
> And there is a limit, per-architecture.
> Many architectures have fixed length instructions.
> On such architectures, going beyond that length does not change the odds of validity,
> though does change the odds of existance (if valid). But our hope is really for invalidity,
> not mere non-existance.
> 
...
...
> 
> Again though, my real goal is to try to remove platform-specificity.
> Something that can be made true for all architectures with no downside, should be made so,
> and the variable removed.
> 
> 
> I'd also like to understand what this all might look like with a portable C generating backend.
> Clearly, reasonably the generated code might need to be able to say:
> ?#if WORD_SIZE == 4 
> ?#if ENDIAN == LITTLE_ENDIAN 
> 
> 
> but hopefully not much else.
> And maybe not even those. :)
> 
> 
> ?- Jay
>  		 	   		  
If you can't find a bit pattern that's code on all architectures, 
neither as code address or as instructions, and you insist on being 
completely target-independent, the only solution I see is to make 
procedure addresses into two-word objects.  Instead of using the pointer 
to the code as procedure address, you use the two-word closure as 
procedure address, and copy those two words around as the address of a 
procedure.  For top-level procedures, use NIL as the environment poi 
ter.

I was really surprised when I discovered that Modula 3 didn't do it this 
way.

It's really a trade-off between data size (procedure pointers being 
bigger) and code size (procedure calls should be fast and avoid a lot of 
run-time checks) 

What does gcc use for the addresses of nested procedures?  Does it 
generate code dynamically on the stack or heap to make it fit into one 
word?

Oh.  There's also a compatibility issue.  To what extent are we 
constrained to use the same coding as C for procedure addresses?

-- hendrik


From jay.krell at cornell.edu  Sun May 30 13:45:36 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 11:45:36 +0000
Subject: [M3devel] the slightly difficult to merge parts 4.3 vs. 4.5
In-Reply-To: <COL101-W641326A298A33186042008E6ED0@phx.gbl>
References: <COL101-W641326A298A33186042008E6ED0@phx.gbl>
Message-ID: <COL101-W9FB75D787ADC38A9E21F1E6ED0@phx.gbl>


I'm understanding this a bit more.
The process of converting "generic" trees to "gimple" seems to have changed a bunch.
The set of tree opcodes and gimple opcodes are now completely seperate I believe -- gimple.def is new.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Sun, 30 May 2010 09:47:21 +0000
> Subject: [M3devel] the slightly difficult to merge parts 4.3 vs. 4.5
>
>
> --- /src/orig/gcc-4.3.0/gcc/tree-gimple.c    2007-12-13 13:49:09.000000000 -0800
> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-gimple.c    2010-05-09 22:27:56.000000000 -0700
> @@ -74,6 +74,7 @@
>      case VECTOR_CST:
>      case OBJ_TYPE_REF:
>      case ASSERT_EXPR:
> +    case STATIC_CHAIN_EXPR:
>        return true;
>
>      default:
>
>
> That is in is gimple_formal_tmp_rhs, which no longer exists, but which the various
> callers do. One obvious guess is callers should each check for STATIC_CHAIN_EXPR.
>
>
>
> tree-nested.c:
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
>
>
> That is in convert_call_expr.
> Which is now called convert_gimple_call, but which is significantly different.
> Hm..I see...there is a new gimple.def, similar to tree.def..
>
> Maybe just have to put STATIC_CHAIN_EXPR in there instead, or
> put a form in each.
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Sun May 30 13:44:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 11:44:29 +0000
Subject: [M3devel] closure marker
In-Reply-To: <20100530065647.GA21438@topoi.pooq.com>
References: <4C017863.2070209@lcwb.coop>,
	<COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>,
	<20100530065647.GA21438@topoi.pooq.com>
Message-ID: <COL101-W29F2F362A57035BBF95F02E6ED0@phx.gbl>


gcc generates code on the stack.
?Which Tony and I both don't like.
? I think you could change it to generate on an executable heap though -- after all, Java and C# do still work.
? And ATL even does this, to get the this pointer to a WindowProc.


We could use a per-target marker if necessary.


We do pass function pointers to C -- window procs, thread entry.
However, we could handled through a little glue code.


As well, we could disallow passing function pointers to <* external *> functions.
Or taking the address of <* external *> functions.


So interesting idea then -- change procedure pointers to be two words, function pointer and static link?
?Too inefficient? Too incompatible? Too big of a change?


Actually toplevel could benefit from non-null static link, for the sake of position independence.
Some C calling conventions do this sort of thing.


?- Jay


----------------------------------------
> Date: Sun, 30 May 2010 02:56:47 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
> On Sun, May 30, 2010 at 07:45:38AM +0000, Jay K wrote:
>>
>>> On the target in question, native word is 64 bits. Closures are three words, as
>>> usual, all 64-bits and aligned to 64 bits.
>>
>> Right.
>> Though I think for IA64 we might need 128bit marker.
>>  At least that is the easy conclusion barring deeper understanding.
>>
> ...
> ...
>>
>>
>> Size and density are the generally dominant performance factors in most systems.
>> Touching the disk to page in stuff is among the slowest operations by far, so
>> reducing size, in order to reduce the number of pages touched, is important.
>>   Bigger code that is deemed "faster" is rarely preferred.
>>   Smaller code is also preferred in "embedded" systems.
>>
> ...
> ...>
>> No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
>> I'm not willing to make that bet.
>> Even the notion of 4 or 8 byte -1 I find tenuous.
>> You cannot portably/easily guarantee that such bytes aren't valid/existant code.
>> You must research all the various architecture encodings.
>>   Granted, we are only talking about function prologues..
>> The longer the sequence, the statistically less likely it is valid or existant code.
>> And there is a limit, per-architecture.
>> Many architectures have fixed length instructions.
>> On such architectures, going beyond that length does not change the odds of validity,
>> though does change the odds of existance (if valid). But our hope is really for invalidity,
>> not mere non-existance.
>>
> ...
> ...
>>
>> Again though, my real goal is to try to remove platform-specificity.
>> Something that can be made true for all architectures with no downside, should be made so,
>> and the variable removed.
>>
>>
>> I'd also like to understand what this all might look like with a portable C generating backend.
>> Clearly, reasonably the generated code might need to be able to say:
>>  #if WORD_SIZE == 4
>>  #if ENDIAN == LITTLE_ENDIAN
>>
>>
>> but hopefully not much else.
>> And maybe not even those. :)
>>
>>
>>  - Jay
>>
> If you can't find a bit pattern that's code on all architectures,
> neither as code address or as instructions, and you insist on being
> completely target-independent, the only solution I see is to make
> procedure addresses into two-word objects. Instead of using the pointer
> to the code as procedure address, you use the two-word closure as
> procedure address, and copy those two words around as the address of a
> procedure. For top-level procedures, use NIL as the environment poi
> ter.
>
> I was really surprised when I discovered that Modula 3 didn't do it this
> way.
>
> It's really a trade-off between data size (procedure pointers being
> bigger) and code size (procedure calls should be fast and avoid a lot of
> run-time checks)
>
> What does gcc use for the addresses of nested procedures? Does it
> generate code dynamically on the stack or heap to make it fit into one
> word?
>
> Oh. There's also a compatibility issue. To what extent are we
> constrained to use the same coding as C for procedure addresses?
>
> -- hendrik
 		 	   		  

From jay.krell at cornell.edu  Sun May 30 20:11:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 18:11:26 +0000
Subject: [M3devel] optimizer doesn't do much?
Message-ID: <COL101-W38377DF1B65EBB708E2D6FE6ED0@phx.gbl>


This little function:


PROCEDURE CallProcx (p: FinallyProc;? VAR a: RT0.RaiseActivation) RAISES ANY =
? BEGIN
??? p (a);
? END CallProcx;


generates all of this at -O2 and above:


_RTExFrame__CallProcx:
??? pushq??? %rbp
??? movq??? %rsp, %rbp
??? subq??? $32, %rsp
???? movq??? %rdi, -24(%rbp)
??? movq??? %rsi, -32(%rbp)
??? movq??? -24(%rbp), %rax ; why not just use %rdi?
??? movq??? %rax, -8(%rbp)
??? movq??? -8(%rbp), %rax ; why? It just stored it!
??? testq??? %rax, %rax
??? je??? L2 ; huh? Compare to NIL, then then just call it anyway?
??? movq??? -8(%rbp), %rax ; why? Again, it is already there.
??? cmpq??? $-1, (%rax)
??? jne??? L2
??? movq??? -8(%rbp), %rax ; why? Again, it is already there.
??? movq??? 16(%rax), %rax
??? movq??? %rax, -16(%rbp)
??? movq??? -8(%rbp), %rax ; again! yeah %rax got clobbered,
??? ?????????????????????? ; but surely it could be using
??? ?????????????????????? ; a different register?
??? movq??? 8(%rax), %rax
??? movq??? %rax, -8(%rbp)
L2:
??? movq??? -8(%rbp), %rax? ; and again
??? movq??? -32(%rbp), %rdi ; %rsi still has it..
??? movq??? -16(%rbp), %r10
??? call??? *%rax
??? leave
??? ret


it is even worse if you omit RAISES ANY.
RAISES ANY saves it from calling pushframe.
and shouldn't it be calling fault_proc for NIL?


Here is what similar C code gets me:
Is this a fair comparison?


typedef void (*F1)(void* chain, void* activation);

typedef struct {
??? long marker;
??? F1 f1;
??? void* chain;
} Closure_t;


void call_F1(Closure_t* cl, void* activation)
{
??? if (cl->marker == -1)
??????? cl->f1(cl->chain, activation);
??? else
??????? ((F1)cl)(0, activation);
}


_call_F1:
??? pushl??? %ebp
??? movl??? %esp, %ebp
??? movl??? 8(%ebp), %ecx
??? movl??? 12(%ebp), %eax
??? cmpl??? $-1, (%ecx)
??? je??? L7
??? movl??? %eax, 12(%ebp)
??? movl??? $0, 8(%ebp)
??? leave
??? jmp??? *%ecx
??? .align 4,0x90
L7:
??? movl??? 8(%ecx), %eax
??? movl??? %eax, 8(%ebp)
??? movl??? 4(%ecx), %ecx
??? leave
??? jmp??? *%ecx


.err..oops different processor:


_call_F1:
??? pushq??? %rbp
??? cmpq??? $-1, (%rdi)
??? movq??? %rdi, %rax
??? movq??? %rsp, %rbp
??? je??? L7
??? xorl??? %edi, %edi
??? movq??? %rax, %r11
??? leave
??? jmp??? *%r11
L7:
??? movq??? 16(%rdi), %rdi
??? movq??? 8(%rax), %r11
??? leave
??? jmp??? *%r11


I don't always care, at least it works, but it does seem surprisingly bad.


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Mon May 31 02:34:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 00:34:32 +0000
Subject: [M3devel] more flailing on STATIC_CHAIN_EXPR
Message-ID: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>


so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
? Not sure the generated code is correct yet, haven't run it.
? I'll keep digging esp. on the existing errors.


However I'm still a bit "confused".


What is the point of STATIC_CHAIN_EXPR?


I still have to try the man/boy example, sorry and thank you.


Back to the question of STATIC_CHAIN_EXPR.


I can see it used in tree-nested.
So it doesn't seem pointless.


However, notice the following:
?gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
?It knows the function is nested. It figures out what references resolve how.
? Locals that are referenced by a nested function are put in a local struct.
? Sometimes by value, sometimes by pointer, depending.
? Non-local references go through the chain, n levels, etc.
? I believe it figures out itself to pass the static link.
? It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.


Now, the parts that I recognize are less automatic:
? static link use can't be optimized away, because it is part of function pointer equality.
? That is what some of our changes to tree-nested are about.
? Furthermore, if it can't be optimized away, it might also be forced to exist in the first place. 
?? Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
? 

The part in 4.5 that says:
DECL_STATIC_CHAIN (decl) = 0;


should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
we can reliably set it in parse.c.


One thing I'm sure I'm missing though is indirect calls.
>From gcc's point of view, indirect calls never? have a static link?
And from ours they always do?
??


This must be key. Direct nested calls need no special support. 
? So a lot will just work.
And all indirect calls need special support, since they might be to a closure.
?


I'll keep trying to understand.


I can get stuff to compile by having m3cg_load_static_link just push nul.
? Feels wrong though. I have to look at the code, but in the RtExFrame example, 
?? it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
?? seems to contain an extra.
When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
wierd behavior like compiler hanging, busy growing arrays very large.


If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
at least to make it go away, else gimplification reasonably complains that it doesn't
know what to do with it.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon May 31 10:26:41 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 31 May 2010 04:26:41 -0400
Subject: [M3devel] more flailing on STATIC_CHAIN_EXPR
In-Reply-To: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>
References: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>
Message-ID: <4521E50B-DF20-467A-B0CC-C5D97D83A42A@cs.purdue.edu>

I suggest you play around with various nested procedure sources and see what code is generated for static chains to understand what is going on.  It has been a long while since I looked at this code and I don't remember all the details.  If I had some time I could probably dredge it up.  But the important thing is that we need to be able to build procedure closures so we need some way to reify the static chain for a procedure.  That's why we need an explicit EXPR.

On 30 May 2010, at 20:34, Jay K wrote:

> 
> so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
>   Not sure the generated code is correct yet, haven't run it.
>   I'll keep digging esp. on the existing errors.
> 
> 
> However I'm still a bit "confused".
> 
> 
> What is the point of STATIC_CHAIN_EXPR?
> 
> 
> I still have to try the man/boy example, sorry and thank you.
> 
> 
> Back to the question of STATIC_CHAIN_EXPR.
> 
> 
> I can see it used in tree-nested.
> So it doesn't seem pointless.
> 
> 
> However, notice the following:
>  gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
>  It knows the function is nested. It figures out what references resolve how.
>   Locals that are referenced by a nested function are put in a local struct.
>   Sometimes by value, sometimes by pointer, depending.
>   Non-local references go through the chain, n levels, etc.
>   I believe it figures out itself to pass the static link.
>   It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.
> 
> 
> Now, the parts that I recognize are less automatic:
>   static link use can't be optimized away, because it is part of function pointer equality.
>   That is what some of our changes to tree-nested are about.
>   Furthermore, if it can't be optimized away, it might also be forced to exist in the first place. 
>    Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
>   
> 
> The part in 4.5 that says:
> DECL_STATIC_CHAIN (decl) = 0;
> 
> 
> should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
> we can reliably set it in parse.c.
> 
> 
> One thing I'm sure I'm missing though is indirect calls.
>> From gcc's point of view, indirect calls never? have a static link?
> And from ours they always do?
> ??
> 
> 
> This must be key. Direct nested calls need no special support. 
>   So a lot will just work.
> And all indirect calls need special support, since they might be to a closure.
> ?
> 
> 
> I'll keep trying to understand.
> 
> 
> I can get stuff to compile by having m3cg_load_static_link just push nul.
>   Feels wrong though. I have to look at the code, but in the RtExFrame example, 
>    it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
>    seems to contain an extra.
> When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
> wierd behavior like compiler hanging, busy growing arrays very large.
> 
> 
> If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
> at least to make it go away, else gimplification reasonably complains that it doesn't
> know what to do with it.
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Mon May 31 10:37:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 08:37:26 +0000
Subject: [M3devel] more flailing on STATIC_CHAIN_EXPR
In-Reply-To: <4521E50B-DF20-467A-B0CC-C5D97D83A42A@cs.purdue.edu>
References: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>,
	<4521E50B-DF20-467A-B0CC-C5D97D83A42A@cs.purdue.edu>
Message-ID: <COL101-W9E39A755BF969730EFD1FE6EE0@phx.gbl>


Ah. That little clue does help.

gcc notices which locals are used in nested functions.
gcc puts those (or pointers to them) in a local struct.
We want the address of that struct so we can store it elsewhere, in our closure.
? (gcc would store it in a trampoline.)


I do have try some small samples, and compile with cm3cg -y..

Thanks,
?- Jay

----------------------------------------
> Subject: Re: [M3devel] more flailing on STATIC_CHAIN_EXPR
> From: hosking at cs.purdue.edu
> Date: Mon, 31 May 2010 04:26:41 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I suggest you play around with various nested procedure sources and see what code is generated for static chains to understand what is going on. It has been a long while since I looked at this code and I don't remember all the details. If I had some time I could probably dredge it up. But the important thing is that we need to be able to build procedure closures so we need some way to reify the static chain for a procedure. That's why we need an explicit EXPR.
>
> On 30 May 2010, at 20:34, Jay K wrote:
>
>>
>> so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
>> Not sure the generated code is correct yet, haven't run it.
>> I'll keep digging esp. on the existing errors.
>>
>>
>> However I'm still a bit "confused".
>>
>>
>> What is the point of STATIC_CHAIN_EXPR?
>>
>>
>> I still have to try the man/boy example, sorry and thank you.
>>
>>
>> Back to the question of STATIC_CHAIN_EXPR.
>>
>>
>> I can see it used in tree-nested.
>> So it doesn't seem pointless.
>>
>>
>> However, notice the following:
>> gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
>> It knows the function is nested. It figures out what references resolve how.
>> Locals that are referenced by a nested function are put in a local struct.
>> Sometimes by value, sometimes by pointer, depending.
>> Non-local references go through the chain, n levels, etc.
>> I believe it figures out itself to pass the static link.
>> It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.
>>
>>
>> Now, the parts that I recognize are less automatic:
>> static link use can't be optimized away, because it is part of function pointer equality.
>> That is what some of our changes to tree-nested are about.
>> Furthermore, if it can't be optimized away, it might also be forced to exist in the first place.
>> Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
>>
>>
>> The part in 4.5 that says:
>> DECL_STATIC_CHAIN (decl) = 0;
>>
>>
>> should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
>> we can reliably set it in parse.c.
>>
>>
>> One thing I'm sure I'm missing though is indirect calls.
>>> From gcc's point of view, indirect calls never? have a static link?
>> And from ours they always do?
>> ??
>>
>>
>> This must be key. Direct nested calls need no special support.
>> So a lot will just work.
>> And all indirect calls need special support, since they might be to a closure.
>> ?
>>
>>
>> I'll keep trying to understand.
>>
>>
>> I can get stuff to compile by having m3cg_load_static_link just push nul.
>> Feels wrong though. I have to look at the code, but in the RtExFrame example,
>> it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
>> seems to contain an extra.
>> When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
>> wierd behavior like compiler hanging, busy growing arrays very large.
>>
>>
>> If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
>> at least to make it go away, else gimplification reasonably complains that it doesn't
>> know what to do with it.
>>
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Mon May 31 10:44:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 08:44:27 +0000
Subject: [M3devel] m3cc -enable-checking=all
Message-ID: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>


????? Configure = Configure & " -enable-checking=all"


enables a bunch of extra checks.
That fail.
With the current 4.3 backend.
I'm going to look into some/all of this.


.1079 = D.1078 & 1
../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
word_64

int_64

int_64

D.1101 = D.1100 & 1
../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
word_64

int_64

int_64

D.1121 = D.1120 & 1
../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
word_64


I think this might be one and only one problem.
The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.

Probably positive constants that fit in the signed type of the same size shouldn't fail.

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Mon May 31 11:50:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 09:50:59 +0000
Subject: [M3devel] m3cc -enable-checking=all
In-Reply-To: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>
References: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>
Message-ID: <COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>


static void
m3cg_and (void)
{
? MTYPE (t);

? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t),
???????????????????????????? EXPR_REF (-2), EXPR_REF (-1));
? EXPR_POP ();
}


Why do we make the result unsigned?

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Mon, 31 May 2010 08:44:27 +0000
> Subject: [M3devel] m3cc -enable-checking=all
>
>
>       Configure = Configure & " -enable-checking=all"
>
>
> enables a bunch of extra checks.
> That fail.
> With the current 4.3 backend.
> I'm going to look into some/all of this.
>
>
> .1079 = D.1078 & 1
> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
> word_64
>
> int_64
>
> int_64
>
> D.1101 = D.1100 & 1
> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
> word_64
>
> int_64
>
> int_64
>
> D.1121 = D.1120 & 1
> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
> word_64
>
>
> I think this might be one and only one problem.
> The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.
>
> Probably positive constants that fit in the signed type of the same size shouldn't fail.
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Mon May 31 12:32:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 10:32:43 +0000
Subject: [M3devel] m3cc -enable-checking=all
In-Reply-To: <COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
References: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>,
	<COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
Message-ID: <COL101-W1AB0D899A46A9622B7612E6EE0@phx.gbl>


-enable_checking=all does find more serious seeming stuff once the noise of int & int => word is removed:


static void
m3cg_pop (void)
{
? UNUSED_MTYPE (t);

? if (TREE_SIDE_EFFECTS (t))
??? add_stmt (EXPR_REF (-1));
? EXPR_POP ();
}


intent was presumably:

static void
m3cg_pop (void)
{
? UNUSED_MTYPE (t);
? tree a = EXPR_REF (-1);

? if (TREE_SIDE_EFFECTS (a))
??? add_stmt (a);
? EXPR_POP ();
}

alas..
introduced I think by rev 1.18 in 2006.
Previously we always set side_effects.


?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Mon, 31 May 2010 09:50:59 +0000
> Subject: Re: [M3devel] m3cc -enable-checking=all
>
>
> static void
> m3cg_and (void)
> {
>   MTYPE (t);
>
>   EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t),
>                              EXPR_REF (-2), EXPR_REF (-1));
>   EXPR_POP ();
> }
>
>
> Why do we make the result unsigned?
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Mon, 31 May 2010 08:44:27 +0000
>> Subject: [M3devel] m3cc -enable-checking=all
>>
>>
>> Configure = Configure & " -enable-checking=all"
>>
>>
>> enables a bunch of extra checks.
>> That fail.
>> With the current 4.3 backend.
>> I'm going to look into some/all of this.
>>
>>
>> .1079 = D.1078 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>> D.1101 = D.1100 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>> D.1121 = D.1120 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>>
>>
>> I think this might be one and only one problem.
>> The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.
>>
>> Probably positive constants that fit in the signed type of the same size shouldn't fail.
>>
>> - Jay
>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Mon May 31 12:57:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 10:57:24 +0000
Subject: [M3devel] m3cc/configure -enable-checks=all non-trivial conversion
 at assignment
Message-ID: <COL101-W72E70FC74CFED51C30F64E6EE0@phx.gbl>


configure -enable-checks=all

../src/M3FP.m3:48: error: non-trivial conversion at assignment
word_64
int_64

????? error ("non-trivial conversion at assignment");
????? debug_generic_expr (TREE_TYPE (lhs));
????? debug_generic_expr (TREE_TYPE (rhs));
????? return true;


gcc doesn't like conversion from word64 to int64.

PROCEDURE ExtendByInt (READONLY a: T;? i: Int): T = (* line 48 *)
? VAR buf: NChars;
? BEGIN
??? FOR x := FIRST (buf) TO LAST (buf) DO
????? buf [x] := VAL (Word.And (i, 16_ff), CHAR);
????? i := Word.Shift (i, -8);? (* line 53 *)
??? END;
??? RETURN Fingerprint.FromChars (buf, a);
? END ExtendByInt;


The line is probably the one with the shift.
Int here is ???? Int = BITS 32 FOR [-16_7fffffff - 1 .. 16_7fffffff];

Presumably we should just build a cast?

I'm guessing the problem is:

(180) set_source_line
? source line?? 53
(181) load
? type:int32
? type:int64?? 
? m3cg_load (M3_ENQ7Kn_i): offset 0x0, convert int32 -> int64
(182) load_integer
? type:int64
? integer i:0xfe n_bytes:0x1 0x00000000000000008 sign -1
(183) shift
? type:word64? <== 
(184) import_procedure
? type:void
? procedure:RTHooks__ReportFault nparams:0x2 rettype:void
(185) declare_param
? type:addr
? param M3_AJWxb1_module type 0xb typeid 0x8402063 bytesize 0x40 alignment 0x40 in_memory 0x0 up_level 0x0
? mode 0x11 (DImode)
(186) declare_param
? type:int64
? param M3_AcxOUs_info type 0x7 typeid 0x195c2a74 bytesize 0x40 alignment 0x40 in_memory 0x0 up_level 0x0
? mode 0x11 (DImode)
(187) set_runtime_proc
(188) check_range
? type:int64
? integer i:0xfa n_bytes:0x4 0x00000000080000000 sign -1
? integer i:0xfb n_bytes:0x4 0x0000000007fffffff sign 1
? check range type 0x7 code 0x1
? declare_fault_proc: type is 0x11 (DImode)
(189) store
? type:int64? <==
? type:int32
? store (M3_ENQ7Kn_i) offset 0x0 src_t int64 dst_t int32
(190) set_source_line
?

The line numbers don't seem to be reported correctly -- we just get the first line of the function.

I don't think this is a serious problem, but probably here:

static void
m3cg_shift (void)
{
? MTYPE (t);

? tree n = declare_temp (t_int);
? tree x = declare_temp (t);

? gcc_assert (INTEGRAL_TYPE_P (t));

? add_stmt (m3_build2 (MODIFY_EXPR, t_int, n, EXPR_REF(-1)));
? add_stmt (m3_build2 (MODIFY_EXPR, t, x, EXPR_REF(-2)));


We should cast 1) assert t is unsigned and 2 ) cast x to it.

I will look into why we don't accidentally ever do arithmetic shift, as gcc does overload the same operand based on type:

/* Shift operations for shift and rotate.
?? Shift means logical shift if done on an
?? unsigned type, arithmetic shift if done on a signed type.
?? The second operand is the number of bits to
?? shift by; it need not be the same type as the first operand and result.
?? Note that the result is undefined if the second operand is larger
?? than or equal to the first operand's type size.? */
DEFTREECODE (LSHIFT_EXPR, "lshift_expr", tcc_binary, 2)
DEFTREECODE (RSHIFT_EXPR, "rshift_expr", tcc_binary, 2)
DEFTREECODE (LROTATE_EXPR, "lrotate_expr", tcc_binary, 2)
DEFTREECODE (RROTATE_EXPR, "rrotate_expr", tcc_binary, 2)


er. actually the problem is on output not input?
shift => word64
but then we do int64 => int32 conversion of the result.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon May 31 19:52:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 31 May 2010 13:52:27 -0400
Subject: [M3devel] m3cc -enable-checking=all
In-Reply-To: <COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
References: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>
	<COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
Message-ID: <795CF2DA-5382-4A83-8536-E51FB3343724@cs.purdue.edu>

Good question.  Shouldn't it be type t?

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 31 May 2010, at 05:50, Jay K wrote:

> 
> static void
> m3cg_and (void)
> {
>   MTYPE (t);
> 
>   EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t),
>                              EXPR_REF (-2), EXPR_REF (-1));
>   EXPR_POP ();
> }
> 
> 
> Why do we make the result unsigned?
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Mon, 31 May 2010 08:44:27 +0000
>> Subject: [M3devel] m3cc -enable-checking=all
>> 
>> 
>>      Configure = Configure & " -enable-checking=all"
>> 
>> 
>> enables a bunch of extra checks.
>> That fail.
>> With the current 4.3 backend.
>> I'm going to look into some/all of this.
>> 
>> 
>> .1079 = D.1078 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>> 
>> int_64
>> 
>> int_64
>> 
>> D.1101 = D.1100 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>> 
>> int_64
>> 
>> int_64
>> 
>> D.1121 = D.1120 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>> 
>> 
>> I think this might be one and only one problem.
>> The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.
>> 
>> Probably positive constants that fit in the signed type of the same size shouldn't fail.
>> 
>> - Jay
>> 
>> 
> 		 	   		  

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

From wagner at elegosoft.com  Mon May  3 17:19:16 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 03 May 2010 17:19:16 +0200
Subject: [M3devel] Solaris x86 support
In-Reply-To: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>
Message-ID: <20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>

Quoting Dagobert Michelsen <dam at opencsw.org>:

> Dear sirs,
>
> I would like to know if there is a version of cm3 for Solaris 10 x86
> available or planned.

Please see trac ticket https://projects.elego.de/cm3/ticket/1084.

This is the second request for CM3 on Solaris/x86.

I forwarded the first one to m3devel, but there has been no response
from any developer yet as far as I know.

As this is an open source project with volunteers working on the code,
there is no centrally controlled plan, and schedules often get updated;
however, I've added the request to the 5.9 milestone for the time being.

Let's see if anybody catches this one... please stay tuned :-)

Best regards,

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 May  3 17:59:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 3 May 2010 15:59:10 +0000
Subject: [M3devel] Solaris x86 support
In-Reply-To: <20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>
Message-ID: <COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>


If someone gives me ssh access to a Solaris machine, then I can do it.
It'd also be a good project for almost anyone to try.
Otherwise I'll get to it eventually.

?- Jay

----------------------------------------
> Date: Mon, 3 May 2010 17:19:16 +0200
> From: wagner at elegosoft.com
> To: dam at opencsw.org
> CC: m3devel at elego.de; m3-support at elego.de
> Subject: Re: [M3devel] Solaris x86 support
>
> Quoting Dagobert Michelsen :
>
>> Dear sirs,
>>
>> I would like to know if there is a version of cm3 for Solaris 10 x86
>> available or planned.
>
> Please see trac ticket https://projects.elego.de/cm3/ticket/1084.
>
> This is the second request for CM3 on Solaris/x86.
>
> I forwarded the first one to m3devel, but there has been no response
> from any developer yet as far as I know.
>
> As this is an open source project with volunteers working on the code,
> there is no centrally controlled plan, and schedules often get updated;
> however, I've added the request to the 5.9 milestone for the time being.
>
> Let's see if anybody catches this one... please stay tuned :-)
>
> Best regards,
>
> 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 May  3 18:15:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 3 May 2010 16:15:13 +0000
Subject: [M3devel] Solaris x86 support
In-Reply-To: <23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>
Message-ID: <COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>


jay or jaykrell or jkrell or whatever you want but tell me (and tell me machine name)
and hopefully your machine doesn't allow remote password logins, only ssh
Presumably you have a working cc and/or gcc.
I can make a local per-user one if needed, but I can probably only do that for gcc.
? Oddly the Solaris 10 x86 VM I had partly up this weekend came with gcc but not cc.
? Made me wonder if gcc is the way..

? - Jay

----------------------------------------
> CC: wagner at elegosoft.com; m3devel at elego.de; m3-support at elego.de
> From: dam at opencsw.org
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] Solaris x86 support
> Date: Mon, 3 May 2010 18:07:34 +0200
>
> Hi Jay,
>
> Am 03.05.2010 um 17:59 schrieb Jay K:
>> If someone gives me ssh access to a Solaris machine, then I can do it.
>> It'd also be a good project for almost anyone to try.
>> Otherwise I'll get to it eventually.
>
> Cool. I just need your intended username and ssh public key.
> Additionally,
> it would be nice if I could name your with the project at the usage
> page at
> 
>>
>
> Best regards
>
> -- Dago
>
>>
>> - Jay
>>
>> ----------------------------------------
>>> Date: Mon, 3 May 2010 17:19:16 +0200
>>> From: wagner at elegosoft.com
>>> To: dam at opencsw.org
>>> CC: m3devel at elego.de; m3-support at elego.de
>>> Subject: Re: [M3devel] Solaris x86 support
>>>
>>> Quoting Dagobert Michelsen :
>>>
>>>> Dear sirs,
>>>>
>>>> I would like to know if there is a version of cm3 for Solaris 10 x86
>>>> available or planned.
>>>
>>> Please see trac ticket https://projects.elego.de/cm3/ticket/1084.
>>>
>>> This is the second request for CM3 on Solaris/x86.
>>>
>>> I forwarded the first one to m3devel, but there has been no response
>>> from any developer yet as far as I know.
>>>
>>> As this is an open source project with volunteers working on the
>>> code,
>>> there is no centrally controlled plan, and schedules often get
>>> updated;
>>> however, I've added the request to the 5.9 milestone for the time
>>> being.
>>>
>>> Let's see if anybody catches this one... please stay tuned :-)
>>>
>>> Best regards,
>>>
>>> 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 --------------
A non-text attachment was scrubbed...
Name: id_dsa.pub
Type: application/octet-stream
Size: 600 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100503/6a23a00e/attachment-0001.obj>

From bugs at elego.de  Mon May  3 21:34:44 2010
From: bugs at elego.de (CM3)
Date: Mon, 03 May 2010 19:34:44 -0000
Subject: [M3devel] [CM3] #1085: Trac Tickets get auto-discarded form
 cm3devel mailing list
Message-ID: <052.c12f607bc89a9ab27900ba1cc75174b6@elego.de>

#1085: Trac Tickets get auto-discarded form cm3devel mailing list
--------------------------------+-------------------------------------------
      Reporter:  mand@?         |        Owner:  wagner
          Type:  support        |       Status:  new   
      Priority:  medium         |    Milestone:        
     Component:  misc           |      Version:  none  
      Severity:  non-critical   |     Keywords:        
       Relnote:                 |          Org:        
Estimatedhours:  0              |        Hours:  0     
      Billable:  1              |   Totalhours:  0     
      Internal:  0              |  
--------------------------------+-------------------------------------------
Htr:
Open or modify a ticket


Fix:
- added "bugs at elego.de" to "auto-accept" list
- added "use_public_cc = true" to cm3 trac.ini


Env:


--------------------------------+-------------------------------------------
 - cc'd tickets from the cm3 trac get autodiscarded
 - no error message or reason given in notification mail
 - suspected causes:
     o bugs at elego.de is not amemeber
     o trac notification plugin sends cc's as bcc

-- 
Ticket URL: <http://projects.elego.de/cm3/ticket/1085>
CM3 <http://projects.elego.de/cm3>
Critical Mass Modula3 Compiler


From wagner at elegosoft.com  Tue May  4 10:23:42 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 04 May 2010 10:23:42 +0200
Subject: [M3devel] Fwd: Auto-discard notification
Message-ID: <20100504102342.ndbo7ov33ks8o8w4@mail.elegosoft.com>

FYI

mailed before subscription was processed...

----- Forwarded message from m3devel-bounces at elegosoft.com -----
     Date: Tue, 04 May 2010 09:18:59 +0200
     From: m3devel-bounces at elegosoft.com
Reply-To: m3devel-bounces at elegosoft.com
  Subject: Auto-discard notification
       To: m3devel-owner at elegosoft.com

The attached message has been automatically discarded.

----- End forwarded message -----

Date: Tue, 4 May 2010 09:11:07 +0200 (CEST)
Subject: some questions
From: Maksimiuk Darek <maxy at online.nl>
To: m3devel at elegosoft.com


Dear All,
  During last  weekend I decide to give a try and play with Modula-3  
language/environment.

  I have installed the  cm3 compiler and libraries on my WinXP box as  
well as on this
  little  PowerPC based machine called EFIKA  
(http://www.bplan-gmbh.de/output.php?PAGE_ID=124,
  http://www.bplan-gmbh.de/output.php?PAGE_ID=135). Unfortunately,  
this computer is no longer produced
  but still available in some places for sale.


  To get it working on the EFIKA I had to upgrade my Debian  
distribution from Etch to Lenny, and
  install the cm3  Linux PowerPC binaries. As far as I can tell, the  
whole process went without any glitches.

  This is the most important part (at least for me) - some questions ...

  1. Is there any (non-Reactor based) development environment for M3  
(emacs, eclipse, etc)?
  2. Are there any active projects that use M3?
  3. Did somebody benchmarked the cm3 compiler against C/C++ (I am  
interested in  the fp number crunching speed)?


  On the daily basis, I am using Matlab, Ada95, and ... Active Oberon  
(running A2 operating system from ETHZ).

  Thanks for your help.

  Regards,
    Darek
-- 
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 dabenavidesd at yahoo.es  Tue May  4 23:29:07 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 4 May 2010 21:29:07 +0000 (GMT)
Subject: [M3devel] Fwd: Auto-discard notification
In-Reply-To: <20100504102342.ndbo7ov33ks8o8w4@mail.elegosoft.com>
Message-ID: <326965.34591.qm@web23603.mail.ird.yahoo.com>

Hi:
welcome to M3 world, I think you will not repent of doing it.
About your questions:
1. Yes, there is a simple environment built on top of emacs (M3ide by Michel Dagenais http://www.professeurs.polymtl.ca/michel.dagenais/pkg/m3ide.tg) and Eclipse plugin too (M3clipse by Bert Laverman http://sourceforge.net/projects/m3clipse/) both are open source and would be nice to have some one who can use it.
2. Yes there are, many commercial, for research and open source projects too; a few worth to name here are the scripting VM based programming language UFO waiting for release, in the research arena there are others like the object oriented data base language Galileo and commercial ones there might be several ones but due trademark restrictions to publish their names some are not known.   
3. I have one reference worth to check in the side of the DEC SRC M3 vs. others a kind of idea of what you might want to know but could be outdated
http://www.dogfish.org/chris/papers/bakeoff/bakeoff.pdf
http://www.dogfish.org/chris/papers/bakeoff/bakeoff.tar.gz
In the new side you can always take times of programs and compare equivalent ones with time, though it might good to automate performance tests like the ones in the code above url tarball.

I hope it helps


--- El mar, 4/5/10, Olaf Wagner <wagner at elegosoft.com> escribi?:

> De: Olaf Wagner <wagner at elegosoft.com>
> Asunto: [M3devel] Fwd: Auto-discard notification
> Para: m3devel at elegosoft.com
> Fecha: martes, 4 de mayo, 2010 03:23
> FYI
> 
> mailed before subscription was processed...
> 
> ----- Forwarded message from m3devel-bounces at elegosoft.com
> -----
>     Date: Tue, 04 May 2010 09:18:59 +0200
>     From: m3devel-bounces at elegosoft.com
> Reply-To: m3devel-bounces at elegosoft.com
>  Subject: Auto-discard notification
>       To: m3devel-owner at elegosoft.com
> 
> The attached message has been automatically discarded.
> 
> ----- End forwarded message -----
> 
> Date: Tue, 4 May 2010 09:11:07 +0200 (CEST)
> Subject: some questions
> From: Maksimiuk Darek <maxy at online.nl>
> To: m3devel at elegosoft.com
> 
> 
> Dear All,
>  During last  weekend I decide to give a try and play
> with Modula-3 language/environment.
> 
>  I have installed the  cm3 compiler and libraries on
> my WinXP box as well as on this
>  little  PowerPC based machine called EFIKA (http://www.bplan-gmbh.de/output.php?PAGE_ID=124,
>  http://www.bplan-gmbh.de/output.php?PAGE_ID=135).
> Unfortunately, this computer is no longer produced
>  but still available in some places for sale.
> 
> 
>  To get it working on the EFIKA I had to upgrade my Debian
> distribution from Etch to Lenny, and
>  install the cm3  Linux PowerPC binaries. As far as I
> can tell, the whole process went without any glitches.
> 
>  This is the most important part (at least for me) - some
> questions ...
> 
>  1. Is there any (non-Reactor based) development
> environment for M3 (emacs, eclipse, etc)?
>  2. Are there any active projects that use M3?
>  3. Did somebody benchmarked the cm3 compiler against C/C++
> (I am interested in  the fp number crunching speed)?
> 
> 
>  On the daily basis, I am using Matlab, Ada95, and ...
> Active Oberon (running A2 operating system from ETHZ).
> 
>  Thanks for your help.
> 
>  Regards,
>    Darek
> --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 May  6 12:17:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 6 May 2010 10:17:43 +0000
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
 Sun cc vs. GNU cc?
In-Reply-To: <C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
Message-ID: <COL101-W178B634DF437CD791F310AE6F50@phx.gbl>


I thought I had sent a followup on this:
 https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html


Can you suggest precise platform name and precise other decisions?


This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
The provided machine's readme says we have Solaris 8, 9, 10 machines,
with multiple versions of Sun and GNU compilers.


Do I just declare that we only support Sun compiler?
Anyone who for some reason wants GNU gets to "rewrite" the config file and keep it to himself?
Or we somehow provide Sun and GNU "configurations" and user can pick one?


Do we have I386_SOLARIS_SUNCC and I386_SOLARIS_GNUCC?
or I386_SOLARIS_CC and I386_SOLARIS_GCC?

or I386_SOLARIS_SUN and I386_SOLARIS_GNU?




I wouldn't mind "helping" people and author the gcc support in quake.
  With some plan to move quake into cm3 in future.
But I don't want this to snowball into having to list extra identical platforms everywhere,
as has been the case for SOLsun and SOLgnu.
  Granted, platform-specific code is extremely rare now.


But the "one target, multiple configurations" of NT386/GNU/MINGNU did seem to get too messy/confusing.


 - Jay


From: hosking at cs.purdue.edu
Subject: Re: [M3devel] new target names -- SOLsun vs. SOLgnu?
Date: Sat, 17 Apr 2010 09:09:08 -0400
To: jay.krell at cornell.edu



Sounds reasonable.

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


On 17 Apr 2010, at 06:50, Jay K wrote:If we have targets, say, I386_NT, I386_CYGWIN, I386_MINGW, I386_LINUX, I386_FREEBSD, I386_NETBSD, SPARC32_SOLARIS or SPARC_SOLARIS..how does one capture the SOLsun vs. SOLgnu difference? SPARC32_SOLARIS_SUN vs. SPARC32_SOLARIS_GNU? SPARC_SOLARIS_SUNCC, SPARC_SOLARIS_GCC?
"target is underscore separated list of relevant names, usually two but not limited to two"?
 
 
Drop SOLgnu and just equate SPARC32_SOLARIS with SOLsun?
Given that the reason for SOLgnu was because cc was not bundled with OS at some point?
  But now gcc and cc are both bundled as I understand!
 
 
Do some sort of autoconfig, sensitive to the CC environment variable?
 That's actually pretty easy and pretty cheap. Not a terrible idea.
 
 
I'm not really pushing hard on this topic, just that I want to cross build Cygwin from non-NT and was hitting minor problems.
Mainly I want to see if Cygwin pthreads works now, now that the hanging test case got "rewritten", so I can drop the SchedulerPosix.m3 file which duplicates content verbatim out of ThreadPThread.m3..
 
 
 - Jay


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

From hosking at cs.purdue.edu  Thu May  6 15:35:26 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 6 May 2010 09:35:26 -0400
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
	Sun cc vs. GNU cc?
In-Reply-To: <COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
Message-ID: <40F00483-654B-4139-827F-5B0A6E466918@cs.purdue.edu>

Is it true that Sun CC is always available on Solaris these days?

On 6 May 2010, at 06:17, Jay K wrote:

> I thought I had sent a followup on this:
>  https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html
> 
> 
> Can you suggest precise platform name and precise other decisions?
> 
> 
> This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
> The provided machine's readme says we have Solaris 8, 9, 10 machines,
> with multiple versions of Sun and GNU compilers.
> 
> 
> Do I just declare that we only support Sun compiler?
> Anyone who for some reason wants GNU gets to "rewrite" the config file and keep it to himself?
> Or we somehow provide Sun and GNU "configurations" and user can pick one?
> 
> 
> Do we have I386_SOLARIS_SUNCC and I386_SOLARIS_GNUCC?
> or I386_SOLARIS_CC and I386_SOLARIS_GCC?
> or I386_SOLARIS_SUN and I386_SOLARIS_GNU?
> 
> 
> I wouldn't mind "helping" people and author the gcc support in quake.
>   With some plan to move quake into cm3 in future.
> But I don't want this to snowball into having to list extra identical platforms everywhere,
> as has been the case for SOLsun and SOLgnu.
>   Granted, platform-specific code is extremely rare now.
> 
> 
> But the "one target, multiple configurations" of NT386/GNU/MINGNU did seem to get too messy/confusing.
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Subject: Re: [M3devel] new target names -- SOLsun vs. SOLgnu?
> Date: Sat, 17 Apr 2010 09:09:08 -0400
> To: jay.krell at cornell.edu
> 
> Sounds reasonable.
> 
> 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 17 Apr 2010, at 06:50, Jay K wrote:
> 
> If we have targets, say, I386_NT, I386_CYGWIN, I386_MINGW, I386_LINUX, I386_FREEBSD, I386_NETBSD, SPARC32_SOLARIS or SPARC_SOLARIS..how does one capture the SOLsun vs. SOLgnu difference? SPARC32_SOLARIS_SUN vs. SPARC32_SOLARIS_GNU? SPARC_SOLARIS_SUNCC, SPARC_SOLARIS_GCC?
> "target is underscore separated list of relevant names, usually two but not limited to two"?
>  
>  
> Drop SOLgnu and just equate SPARC32_SOLARIS with SOLsun?
> Given that the reason for SOLgnu was because cc was not bundled with OS at some point?
>   But now gcc and cc are both bundled as I understand!
>  
>  
> Do some sort of autoconfig, sensitive to the CC environment variable?
>  That's actually pretty easy and pretty cheap. Not a terrible idea.
>  
>  
> I'm not really pushing hard on this topic, just that I want to cross build Cygwin from non-NT and was hitting minor problems.
> Mainly I want to see if Cygwin pthreads works now, now that the hanging test case got "rewritten", so I can drop the SchedulerPosix.m3 file which duplicates content verbatim out of ThreadPThread.m3..
>  
>  
>  - Jay
> 
> 
> 

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

From dam at opencsw.org  Thu May  6 15:51:43 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 6 May 2010 15:51:43 +0200
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
	Sun cc vs. GNU cc?
In-Reply-To: <40F00483-654B-4139-827F-5B0A6E466918@cs.purdue.edu>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
	<40F00483-654B-4139-827F-5B0A6E466918@cs.purdue.edu>
Message-ID: <3B937FEC-0A36-4A04-A943-7F1A1A5756F6@opencsw.org>

Hi Tony,

Am 06.05.2010 um 15:35 schrieb Tony Hosking:
> Is it true that Sun CC is always available on Solaris these days?

It is not bundled with the OS, but it can be downloaded separately for  
free.


Best regards

   -- Dago



From mika at async.async.caltech.edu  Thu May  6 22:01:19 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 06 May 2010 13:01:19 -0700
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
	Sun cc vs. GNU cc?
In-Reply-To: <COL101-W178B634DF437CD791F310AE6F50@phx.gbl> 
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
Message-ID: <20100506200119.099571A209B@async.async.caltech.edu>

Jay K writes:
>--_5e9c7792-d671-4ede-8a4b-673a7203ffec_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>I thought I had sent a followup on this:
> https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html
>
>
>Can you suggest precise platform name and precise other decisions?
>
>
>This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
>The provided machine's readme says we have Solaris 8=2C 9=2C 10 machines=2C
>with multiple versions of Sun and GNU compilers.
>
>
>Do I just declare that we only support Sun compiler?
>Anyone who for some reason wants GNU gets to "rewrite" the config file and =
>keep it to himself?
>Or we somehow provide Sun and GNU "configurations" and user can pick one?

Does Sun's cc (or whatever is needed of it to make CM3 work) come free
nowadays?  It used to be a pay package on Solaris.

    Mika


From jay.krell at cornell.edu  Thu May  6 22:13:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 6 May 2010 20:13:07 +0000
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu?
	I386_SOLARIS	Sun cc vs. GNU cc?
In-Reply-To: <20100506200119.099571A209B@async.async.caltech.edu>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>, ,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>,
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>,
	<20100506200119.099571A209B@async.async.caltech.edu>
Message-ID: <COL101-W455ADF4C96225C281BC2AAE6F50@phx.gbl>


Yes it is free of cost. But maybe people still prefer gcc for some reason?
e.g. they have some Linux/sparc assembly?
or use gcc extensions?
We generally don't do either in the Modula-3 libraries, since we already compile with Sun cc for Sparc.
 
Or for cross build purposes?
 That can be pretty powerful -- building a full gcc+ld cross toolset. I'm using that for VMS currently (for ld you have to use trunk, the support isn't in the latest release). Though binutils/ld/gas support is a little spotty outside of Linux, generally not as much as gcc. And you have to copy the headers/libraries from the target machine.
 
 
 - Jay



----------------------------------------
> To: jay.krell at cornell.edu
> Date: Thu, 6 May 2010 13:01:19 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS Sun cc vs. GNU cc?
>
> Jay K writes:
>>--_5e9c7792-d671-4ede-8a4b-673a7203ffec_
>>Content-Type: text/plain; charset="iso-8859-1"
>>Content-Transfer-Encoding: quoted-printable
>>
>>
>>I thought I had sent a followup on this:
>> https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html
>>
>>
>>Can you suggest precise platform name and precise other decisions?
>>
>>
>>This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
>>The provided machine's readme says we have Solaris 8=2C 9=2C 10 machines=2C
>>with multiple versions of Sun and GNU compilers.
>>
>>
>>Do I just declare that we only support Sun compiler?
>>Anyone who for some reason wants GNU gets to "rewrite" the config file and =
>>keep it to himself?
>>Or we somehow provide Sun and GNU "configurations" and user can pick one?
>
> Does Sun's cc (or whatever is needed of it to make CM3 work) come free
> nowadays? It used to be a pay package on Solaris.
>
> Mika 		 	   		  

From peter.mckinna at gmail.com  Sat May  8 06:22:12 2010
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sat, 8 May 2010 14:22:12 +1000
Subject: [M3devel] Compile Options
Message-ID: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>

Hey,

  Using -c to disable library or program generation does not seem to work.
Also how do you turn off debug symbol generation?
And the -O switch doesnt seem to optimise anything.

  Is it just me or the documentation.

Regards

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100508/835dbed7/attachment-0001.html>

From hosking at cs.purdue.edu  Sat May  8 06:55:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 8 May 2010 00:55:10 -0400
Subject: [M3devel] Compile Options
In-Reply-To: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
Message-ID: <C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>

What target platform?

On 8 May 2010, at 00:22, Peter McKinna wrote:

> Hey,
> 
>   Using -c to disable library or program generation does not seem to work. Also how do you turn off debug symbol generation?
> And the -O switch doesnt seem to optimise anything.
> 
>   Is it just me or the documentation.
> 
> Regards
> 
> Peter



From jay.krell at cornell.edu  Sat May  8 06:58:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 04:58:40 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
Message-ID: <COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>


-O is the config files
It gets passed on to them and they may or may not pay attention.

Turning off symbol generation not something I'm very sympathetic too.
I realize it cuts I/O, build time, resulting binary size (possibly load/runtime,
depending on the load behavior of symbols). Though on Windows
the symbols go into separate files, greatly reducing any negative affect.
On one hand, you don't want to inhibit debugging,
but on the other, we don't have a good debugger story anyway.
Again, check the config files.

-c I don't know. Is it important?

?- Jay

________________________________
> Date: Sat, 8 May 2010 14:22:12 +1000
> From: peter.mckinna at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Compile Options
>
> Hey,
>
> Using -c to disable library or program generation does not seem to work. Also how do you turn off debug symbol generation?
> And the -O switch doesnt seem to optimise anything.
>
> Is it just me or the documentation.
>
>
> Regards
>
> Peter
 		 	   		  

From wagner at elegosoft.com  Sat May  8 12:40:04 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 08 May 2010 12:40:04 +0200
Subject: [M3devel] Compile Options
In-Reply-To: <COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>
Message-ID: <20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>

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

> -O is the config files
> It gets passed on to them and they may or may not pay attention.
>
> Turning off symbol generation not something I'm very sympathetic too.
> I realize it cuts I/O, build time, resulting binary size (possibly   
> load/runtime,
> depending on the load behavior of symbols). Though on Windows
> the symbols go into separate files, greatly reducing any negative affect.
> On one hand, you don't want to inhibit debugging,

Of course you may want to strip symbols for programs delivered to
customers.

> but on the other, we don't have a good debugger story anyway.

m3gdb works well on certain platforms.

> Again, check the config files.
>
> -c I don't know. Is it important?

The front end just includes some quake calls in the generated
m3make file for the options:

% less AMD64_FREEBSD/m3make.args
set_config_options ()
readonly _all = TRUE % cm3 -build
m3_optimize (TRUE)                  <----
m3_debug (TRUE)                     <----
M3_KEEP_FILES = TRUE
m3_compile_only ()                  <----
M3_MODE = "build"
include_dir ("../src")

At least optimize and debug used to work some time ago; I'm not
sure about compile-only.

Was something lost during the great config refactoring?
Can you please check that, Jay?

I think we shold implement the CLI as documented. We _might_ discuss
the value-add of -c (I've never used it).

We're probably missing regression tests for these simple command line
arguments, too.

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  Sat May  8 18:01:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 8 May 2010 12:01:12 -0400
Subject: [M3devel] Compile Options
In-Reply-To: <20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
Message-ID: <EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>

-O used to work in the old config files.
Did it get lost?

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 8 May 2010, at 06:40, Olaf Wagner wrote:

> Quoting Jay K <jay.krell at cornell.edu>:
> 
>> -O is the config files
>> It gets passed on to them and they may or may not pay attention.
>> 
>> Turning off symbol generation not something I'm very sympathetic too.
>> I realize it cuts I/O, build time, resulting binary size (possibly  load/runtime,
>> depending on the load behavior of symbols). Though on Windows
>> the symbols go into separate files, greatly reducing any negative affect.
>> On one hand, you don't want to inhibit debugging,
> 
> Of course you may want to strip symbols for programs delivered to
> customers.
> 
>> but on the other, we don't have a good debugger story anyway.
> 
> m3gdb works well on certain platforms.
> 
>> Again, check the config files.
>> 
>> -c I don't know. Is it important?
> 
> The front end just includes some quake calls in the generated
> m3make file for the options:
> 
> % less AMD64_FREEBSD/m3make.args
> set_config_options ()
> readonly _all = TRUE % cm3 -build
> m3_optimize (TRUE)                  <----
> m3_debug (TRUE)                     <----
> M3_KEEP_FILES = TRUE
> m3_compile_only ()                  <----
> M3_MODE = "build"
> include_dir ("../src")
> 
> At least optimize and debug used to work some time ago; I'm not
> sure about compile-only.
> 
> Was something lost during the great config refactoring?
> Can you please check that, Jay?
> 
> I think we shold implement the CLI as documented. We _might_ discuss
> the value-add of -c (I've never used it).
> 
> We're probably missing regression tests for these simple command line
> arguments, too.
> 
> 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/20100508/f9331286/attachment-0001.html>

From jay.krell at cornell.edu  Sun May  9 00:21:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 22:21:59 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>,
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>,
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>,
	<EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>
Message-ID: <COL101-W4501E007067E4DA24A83D6E6F70@phx.gbl>


-O looks right for the vast majority of targets (Unix.common: *BSD, Solaris, Darwin, Linux, maybe not NT/Interix/Cygwin/VMS).
I'll adjust -g/-gstabs+ (PA64_HPUX never generates symbols currently, since it doesn't support stabs)
I have some more config file cleanup on deck: moving m3back_flags out of per-target and to per-architecture, though even that is necessary duplication


I propose also that -O should imply -O2, not -O3.
?-O2 seems to be heavily used in the wider world, -O3 not so much 
?For one thing, gcc itself defaults to building with -O2.

I have it like this:

if not defined("m3back_optimize")
?m3back_optimize = "-O2"
end

if not defined("m3back_debug")
?
m3back_debug = "-gstaus+"

end


and then
if optimize options += m3back_optimize end
if debug options += m3back_debug? end




individual users/platforms can override, such as PA64_HPUX setting m3back_debug = "" (maybe later to something else)
maybe we can shift to dwarf at some point too, that seems to be the favored format on most platforms


?- Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Sat, 8 May 2010 12:01:12 -0400
> To: wagner at elegosoft.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compile Options
>
>
>
> -O used to work in the old config files.
> Did it get lost?
>
>
> 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 8 May 2010, at 06:40, Olaf Wagner wrote:
>
> Quoting Jay K>:
>
> -O is the config files
> It gets passed on to them and they may or may not pay attention.
>
> Turning off symbol generation not something I'm very sympathetic too.
> I realize it cuts I/O, build time, resulting binary size (possibly load/runtime,
> depending on the load behavior of symbols). Though on Windows
> the symbols go into separate files, greatly reducing any negative affect.
> On one hand, you don't want to inhibit debugging,
>
> Of course you may want to strip symbols for programs delivered to
> customers.
>
> but on the other, we don't have a good debugger story anyway.
>
> m3gdb works well on certain platforms.
>
> Again, check the config files.
>
> -c I don't know. Is it important?
>
> The front end just includes some quake calls in the generated
> m3make file for the options:
>
> % less AMD64_FREEBSD/m3make.args
> set_config_options ()
> readonly _all = TRUE % cm3 -build
> m3_optimize (TRUE) <----
> m3_debug (TRUE) <----
> M3_KEEP_FILES = TRUE
> m3_compile_only () <----
> M3_MODE = "build"
> include_dir ("../src")
>
> At least optimize and debug used to work some time ago; I'm not
> sure about compile-only.
>
> Was something lost during the great config refactoring?
> Can you please check that, Jay?
>
> I think we shold implement the CLI as documented. We _might_ discuss
> the value-add of -c (I've never used it).
>
> We're probably missing regression tests for these simple command line
> arguments, too.
>
> 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 May  9 00:31:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 22:31:09 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <COL101-W4501E007067E4DA24A83D6E6F70@phx.gbl>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>, ,
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>, ,
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>, ,
	<EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>,
	<COL101-W4501E007067E4DA24A83D6E6F70@phx.gbl>
Message-ID: <COL101-W25C8957E8FB3C0461CD852E6F70@phx.gbl>


I assume currently -g can't be turned off, because cm3cfg.common:

proc set_config_options() is
??? m3_option("-why")?? %-- produce a listing that explains what's happening and why
??? m3_debug(TRUE)????? %-- produce object code with debugging symbols
??? M3_OPTIONS += "-w1" %-- produce "level 1" warnings
end

Which was probably always like that but I'm not sure, I only sampled one historical file just now.
We should maybe have -g0 to turn it off?

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; wagner at elegosoft.com
> Date: Sat, 8 May 2010 22:21:59 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compile Options
>
>
> -O looks right for the vast majority of targets (Unix.common: *BSD, Solaris, Darwin, Linux, maybe not NT/Interix/Cygwin/VMS).
> I'll adjust -g/-gstabs+ (PA64_HPUX never generates symbols currently, since it doesn't support stabs)
> I have some more config file cleanup on deck: moving m3back_flags out of per-target and to per-architecture, though even that is necessary duplication
>
>
> I propose also that -O should imply -O2, not -O3.
>  -O2 seems to be heavily used in the wider world, -O3 not so much
>  For one thing, gcc itself defaults to building with -O2.
>
> I have it like this:
>
> if not defined("m3back_optimize")
>  m3back_optimize = "-O2"
> end
>
> if not defined("m3back_debug")
>
> m3back_debug = "-gstaus+"
>
> end
>
>
> and then
> if optimize options += m3back_optimize end
> if debug options += m3back_debug  end
>
>
>
>
> individual users/platforms can override, such as PA64_HPUX setting m3back_debug = "" (maybe later to something else)
> maybe we can shift to dwarf at some point too, that seems to be the favored format on most platforms
>
>
>  - Jay
>
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Sat, 8 May 2010 12:01:12 -0400
>> To: wagner at elegosoft.com
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Compile Options
>>
>>
>>
>> -O used to work in the old config files.
>> Did it get lost?
>>
>>
>> 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 8 May 2010, at 06:40, Olaf Wagner wrote:
>>
>> Quoting Jay K>:
>>
>> -O is the config files
>> It gets passed on to them and they may or may not pay attention.
>>
>> Turning off symbol generation not something I'm very sympathetic too.
>> I realize it cuts I/O, build time, resulting binary size (possibly load/runtime,
>> depending on the load behavior of symbols). Though on Windows
>> the symbols go into separate files, greatly reducing any negative affect.
>> On one hand, you don't want to inhibit debugging,
>>
>> Of course you may want to strip symbols for programs delivered to
>> customers.
>>
>> but on the other, we don't have a good debugger story anyway.
>>
>> m3gdb works well on certain platforms.
>>
>> Again, check the config files.
>>
>> -c I don't know. Is it important?
>>
>> The front end just includes some quake calls in the generated
>> m3make file for the options:
>>
>> % less AMD64_FREEBSD/m3make.args
>> set_config_options ()
>> readonly _all = TRUE % cm3 -build
>> m3_optimize (TRUE) <----
>> m3_debug (TRUE) <----
>> M3_KEEP_FILES = TRUE
>> m3_compile_only () <----
>> M3_MODE = "build"
>> include_dir ("../src")
>>
>> At least optimize and debug used to work some time ago; I'm not
>> sure about compile-only.
>>
>> Was something lost during the great config refactoring?
>> Can you please check that, Jay?
>>
>> I think we shold implement the CLI as documented. We _might_ discuss
>> the value-add of -c (I've never used it).
>>
>> We're probably missing regression tests for these simple command line
>> arguments, too.
>>
>> 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  Sun May  9 01:43:09 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 08 May 2010 16:43:09 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu> 
References: <20100508220958.8EA242474003@birch.elegosoft.com>,
	<62B45315-F33E-4586-BCCE-CE57F5E307EA@cs.purdue.edu>
	<COL101-W455DE8BD33138D220620E6E6F70@phx.gbl>,
	<C7985D61-0C4C-44B8-ACBE-2548725E3153@cs.purdue.edu>
	<COL101-W94565E47A143953025584E6F70@phx.gbl>
	<6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu>
Message-ID: <20100508234309.937D21A2095@async.async.caltech.edu>

I've been following the discussion at a distance and am trying to understand
what problem is being guarded against?

The possibility that users change the signal mask?  Signal mask is not
part of Modula-3.  I think a programmer who messes with the signal mask
shouldn't expect Modula-3 to restore it for him when it switches threads,
processes exceptions, etc.

If you want to provide hooks for it that would be nice but I think it's
strictly optional.

"Correctness" should (as always) mean correctness w.r.t. the Green Book,
which makes no mention at all of signals... It does mention FloatMode
however (page 75).

    Mika

Tony Hosking writes:
>
>--Apple-Mail-78-848772270
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=us-ascii
>
>I think we can argue that a programmer should program around this using =
>TRY...FINALLY (i.e., even if they used FloatMode).
>
>So, I think we are safe with jmpbuf instead of sigjmpbuf.
>
>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 8 May 2010, at 18:56, Jay K wrote:
>
>>=20
>> Is "proper" saving/restoring as much as we can think of, or is it =
>fast, or is it matching Ada and C++, or .. ?
>> Ada and C++ (gnat and g++) have often/historically used =
>setjmp/longjmp.
>>   configure -enable-sjlj-exceptions
>> It might be interesting to see if they try to avoid the signal mask =
>versions when they use setjmp/longjmp.
>> Lately they use table-based unwinding on platforms that they can -- =
>which is to say, I *really* doubt
>> they save/restore the signal mask, but they might.
>>=20
>>=20
>>  - Jay
>>=20
>> ----------------------------------------
>>> Subject: Re: [M3commit] CVS Update: cm3
>>> From: hosking at cs.purdue.edu
>>> Date: Sat, 8 May 2010 18:51:18 -0400
>>> CC: jkrell at elego.de; m3commit at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>=20
>>>=20
>>>=20
>>> On 8 May 2010, at 18:38, Jay K wrote:
>>>=20
>>>> Or, understood, you really think we might throw around a signal mask =
>change?
>>>=20
>>> It's possible.
>>>=20
>>>> Realize also that sigsetjmp or setjmp, whichever we use, is called =
>incredibly often, and sigsetjmp is likely
>>>> much much slower. Also notice..this I'll have to check...have we =
>ever called sigsetjmp?
>>>> Well, no, I doubt it. But maybe setjmp vs. _setjmp.
>>>> Again though, this can be significantly slow.
>>>>=20
>>>>=20
>>>> Ultimately as well...see..I started this email without a firm =
>opinion, but now I'm "firming" toward the change I made.
>>>> Consider C++ exceptions. Consider libunwind. Consider the SPARC =
>stack walker (which I have to look at).
>>>> Do they save/restore signal masks? I doubt it. Maybe. We can look =
>into it. But I doubt it.
>>>=20
>>> We should confirm.
>>>=20
>>>> Raising an exception can indeed by slow. But entering a function =
>with finally (or destructors) should not be overly so.
>>>=20
>>> Ultimately, we should use proper stack unwinding wherever possible.
>>>=20
>>>>=20
>>>>=20
>>>> - Jay
>>>>=20
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Sat, 8 May 2010 18:28:36 -0400
>>>>> To: jkrell at elego.de
>>>>> CC: m3commit at elegosoft.com
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>=20
>>>>> Ah, now I remember. sigjmpbuf is important for unwinding on =
>exception to make sure that if we unwind through a frame where the =
>programmer changed the signal mask that we also restore the signal mask =
>of the caller. I think you also probably break things like FloatMode by =
>not restoring the signal mask properly.
>>>>>=20
>>>>> On 9 May 2010, at 00:09, Jay Krell wrote:
>>>>>=20
>>>>>> CVSROOT: /usr/cvs
>>>>>> Changes by: jkrell at birch. 10/05/09 00:09:58
>>>>>>=20
>>>>>> Modified files:
>>>>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3
>>>>>>=20
>>>>>> Log message:
>>>>>> add SPARC32_SOLARIS
>>>>>>=20
>>>>>> correct jmpbuf sizes for I386_SOLARIS, AMD64_SOLARIS
>>>>>> notice again that jmpbuf is much much smaller than sigjmpbuf,
>>>>>> and this is jmpbuf; specifically:
>>>>>> I386_SOLARIS jmpbuf 40 bytes with 4 align
>>>>>> AMD64_SOLARIS jmpbuf 64 bytes with 8 align
>>>>>> I386_SOLARIS sigjmpbuf 512 bytes with 4 align
>>>>>> AMD64_SOLARIS sigjmpbuf 1024 bytes with 8 align
>>>>>>=20
>>>>>> remove some level of heap allocation of calling conventions
>>>>>>=20
>>>>>> accept all calling conventions for all targets
>>>>>> Only NT386 has calling conventions, and it *highly* likely
>>>>>> the only target ever to have them, therefore the mechanism
>>>>>> does not need to be further generalized. (MIPS32 has two
>>>>>> ABIs, but those will probably be two targets)
>>>>>> This might let us save some unnecessary forking of *.i3 files.
>>>>>> The initialization here can be further streamlined.
>>>>>>=20
>>>>>> shrink SOLgnu/SOLsun from sigjmpbuf to jmpbuf
>>>>>> I'm not sure we use this though since we have a stack walker.
>>>>>> fix SPARC64_SOLARIS too to be smaller
>>>>>>=20
>>>>>> SPARC32_SOLARIS
>>>>>> jmpbuf size: 48
>>>>>> sigjmpbuf size: 76
>>>>>> alignment: 4 4
>>>>>>=20
>>>>>> SPARC64_SOLARIS
>>>>>> jmpbuf size: 96
>>>>>> sigjmpbuf size: 152
>>>>>> alignment: 8 8
>>>>>=20
>>>>=20
>>>=20
>> 		 	   		 =20
>
>
>--Apple-Mail-78-848772270
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/html;
>	charset=us-ascii
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I =
>think we can argue that a programmer should program around this using =
>TRY...FINALLY (i.e., even if they used =
>FloatMode).<div><br></div><div>So, I think we are safe with jmpbuf =
>instead of sigjmpbuf.<br><div><br><div>
><span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
>auto; text-indent: 0px; text-transform: none; white-space: normal; =
>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF"><font =
>class=3D"Apple-style-span" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Antony =
>Hosking</span></span></font></font><font class=3D"Apple-style-span" =
>face=3D"Gill Sans"><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-converted-space">&nbsp;</span>|<span =
>class=3D"Apple-converted-space">&nbsp;</span></span></span><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; "><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; =
>">Associate Professor</span></span><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; "><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; ">&nbsp;| Computer Science | Purdue =
>University</span></span></font></div><div><font class=3D"Apple-style-span"=
> face=3D"GillSans-Light"><span class=3D"Apple-style-span" =
>style=3D"font-family: GillSans-Light; ">305 N. University Street | West =
>Lafayette | IN 47907 | USA</span></font></div><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Office</span></span></font><font =
>class=3D"Apple-style-span" face=3D"GillSans-Light"><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; =
>">&nbsp;+1 765 494 6001 |<span =
>class=3D"Apple-converted-space">&nbsp;</span></span></span></font><font =
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Mobile</span></span></font><font =
>class=3D"Apple-style-span" face=3D"GillSans-Light"><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-converted-space">&nbsp;</span>+1 765 427 =
>5484</span></span></font></div><div><font class=3D"Apple-style-span" =
>face=3D"GillSans-Light"><br =
>class=3D"khtml-block-placeholder"></font></div></span></span></span></span=
>></span></span></span><br =
>class=3D"Apple-interchange-newline"></span></div></span></span><br =
>class=3D"Apple-interchange-newline">
></div>
><br><div><div>On 8 May 2010, at 18:56, Jay K wrote:</div><br =
>class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><br>Is =
>"proper" saving/restoring as much as we can think of, or is it fast, or =
>is it matching Ada and C++, or .. ?<br>Ada and C++ (gnat and g++) have =
>often/historically used setjmp/longjmp.<br>&nbsp; configure =
>-enable-sjlj-exceptions<br>It might be interesting to see if they try to =
>avoid the signal mask versions when they use setjmp/longjmp.<br>Lately =
>they use table-based unwinding on platforms that they can -- which is to =
>say, I *really* doubt<br>they save/restore the signal mask, but they =
>might.<br><br><br>&nbsp;- =
>Jay<br><br>----------------------------------------<br><blockquote =
>type=3D"cite">Subject: Re: [M3commit] CVS Update: =
>cm3<br></blockquote><blockquote type=3D"cite">From: <a =
>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu</a><br></block=
>quote><blockquote type=3D"cite">Date: Sat, 8 May 2010 18:51:18 =
>-0400<br></blockquote><blockquote type=3D"cite">CC: <a =
>href=3D"mailto:jkrell at elego.de">jkrell at elego.de</a>; <a =
>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com</a><br></blo=
>ckquote><blockquote type=3D"cite">To: <a =
>href=3D"mailto:jay.krell at cornell.edu">jay.krell at cornell.edu</a><br></block=
>quote><blockquote type=3D"cite"><br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">On 8 May 2010, =
>at 18:38, Jay K wrote:<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">Or, understood, you really think we might throw around a =
>signal mask change?<br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">It's =
>possible.<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">Realize also that sigsetjmp or setjmp, whichever we use, =
>is called incredibly often, and sigsetjmp is =
>likely<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">much much slower. Also notice..this I'll have to =
>check...have we ever called =
>sigsetjmp?<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Well, no, I doubt it. But maybe =
>setjmp vs. _setjmp.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Again though, this can be =
>significantly slow.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Ultimately as well...see..I =
>started this email without a firm opinion, but now I'm "firming" toward =
>the change I made.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Consider C++ exceptions. =
>Consider libunwind. Consider the SPARC stack walker (which I have to =
>look at).<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Do they save/restore signal =
>masks? I doubt it. Maybe. We can look into it. But I doubt =
>it.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">We should =
>confirm.<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">Raising an exception can indeed by slow. But entering a =
>function with finally (or destructors) should not be overly =
>so.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">Ultimately, we =
>should use proper stack unwinding wherever =
>possible.<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">- =
>Jay<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite">----------------------------------------<br></blockquote></b=
>lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite">From: <a =
>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu</a><br></block=
>quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Date: Sat, 8 May 2010 18:28:36 =
>-0400<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To: <a =
>href=3D"mailto:jkrell at elego.de">jkrell at elego.de</a><br></blockquote></bloc=
>kquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">CC: <a =
>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com</a><br></blo=
>ckquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Subject: Re: [M3commit] CVS =
>Update: cm3<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Ah, =
>now I remember. sigjmpbuf is important for unwinding on exception to =
>make sure that if we unwind through a frame where the programmer changed =
>the signal mask that we also restore the signal mask of the caller. I =
>think you also probably break things like FloatMode by not restoring the =
>signal mask =
>properly.<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">On 9 =
>May 2010, at 00:09, Jay Krell =
>wrote:<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">CVSROOT: =
>/usr/cvs<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Changes by: jkrell at birch. =
>10/05/09 =
>00:09:58<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Modified =
>files:<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">cm3/m3-sys/m3middle/src/: =
>Target.i3 =
>Target.m3<br></blockquote></blockquote></blockquote></blockquote><blockquo=
>te type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Log =
>message:<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">add =
>SPARC32_SOLARIS<br></blockquote></blockquote></blockquote></blockquote><bl=
>ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">correct jmpbuf sizes for =
>I386_SOLARIS, =
>AMD64_SOLARIS<br></blockquote></blockquote></blockquote></blockquote><bloc=
>kquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">notice again that jmpbuf is much =
>much smaller than =
>sigjmpbuf,<br></blockquote></blockquote></blockquote></blockquote><blockqu=
>ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">and this is jmpbuf; =
>specifically:<br></blockquote></blockquote></blockquote></blockquote><bloc=
>kquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">I386_SOLARIS jmpbuf 40 bytes =
>with 4 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">AMD64_SOLARIS jmpbuf 64 bytes =
>with 8 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">I386_SOLARIS sigjmpbuf 512 bytes =
>with 4 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">AMD64_SOLARIS sigjmpbuf 1024 =
>bytes with 8 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">remove some level of heap =
>allocation of calling =
>conventions<br></blockquote></blockquote></blockquote></blockquote><blockq=
>uote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">accept all calling conventions =
>for all =
>targets<br></blockquote></blockquote></blockquote></blockquote><blockquote=
> type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Only NT386 has calling =
>conventions, and it *highly* =
>likely<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">the only target ever to have =
>them, therefore the =
>mechanism<br></blockquote></blockquote></blockquote></blockquote><blockquo=
>te type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">does not need to be further =
>generalized. (MIPS32 has =
>two<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">ABIs, but those will probably be =
>two =
>targets)<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">This might let us save some =
>unnecessary forking of *.i3 =
>files.<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">The initialization here can be =
>further =
>streamlined.<br></blockquote></blockquote></blockquote></blockquote><block=
>quote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">shrink SOLgnu/SOLsun from =
>sigjmpbuf to =
>jmpbuf<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">I'm not sure we use this though =
>since we have a stack =
>walker.<br></blockquote></blockquote></blockquote></blockquote><blockquote=
> type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">fix SPARC64_SOLARIS too to be =
>smaller<br></blockquote></blockquote></blockquote></blockquote><blockquote=
> type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite">SPARC32_SOLARIS<br></blockquote></blockquote></blockquote></=
>blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote=
> type=3D"cite"><blockquote type=3D"cite">jmpbuf size: =
>48<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">sigjmpbuf size: =
>76<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">alignment: 4 =
>4<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite">SPARC64_SOLARIS<br></blockquote></blockquote></blockquote></=
>blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote=
> type=3D"cite"><blockquote type=3D"cite">jmpbuf size: =
>96<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">sigjmpbuf size: =
>152<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">alignment: 8 =
>8<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote> <span class=3D"Apple-tab-span" =
>style=3D"white-space:pre">	</span><span class=3D"Apple-tab-span" =
>style=3D"white-space:pre">	</span> <span class=3D"Apple-tab-span" =
>style=3D"white-space:pre">	</span> &nbsp;&nbsp;<span =
>class=3D"Apple-tab-span" style=3D"white-space:pre">	</span><span =
>class=3D"Apple-tab-span" style=3D"white-space:pre">	</span> =
>&nbsp;<br></div></blockquote></div><br></div></div></body></html>=
>
>--Apple-Mail-78-848772270--


From jay.krell at cornell.edu  Sun May  9 01:49:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 23:49:13 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20100508234309.937D21A2095@async.async.caltech.edu>
References: <20100508220958.8EA242474003@birch.elegosoft.com>, ,
	<62B45315-F33E-4586-BCCE-CE57F5E307EA@cs.purdue.edu>,
	<COL101-W455DE8BD33138D220620E6E6F70@phx.gbl>, ,
	<C7985D61-0C4C-44B8-ACBE-2548725E3153@cs.purdue.edu>,
	<COL101-W94565E47A143953025584E6F70@phx.gbl>,
	<6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu>,
	<20100508234309.937D21A2095@async.async.caltech.edu>
Message-ID: <COL101-W487024C8B81D4B8120C348E6F70@phx.gbl>


It's not a closed system. Modula-3 can call C can call C++ can call Modula-3, etc., and they can call raise exceptions.
I'm not sure what the C exception story is on all platforms, but at least on Windows there is RaiseException.

Green book doesn't mention m3-libs/m3core/src/Unix, but it exists anyway.

?- Jay

----------------------------------------
> To: hosking at cs.purdue.edu
> Date: Sat, 8 May 2010 16:43:09 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> I've been following the discussion at a distance and am trying to understand
> what problem is being guarded against?
>
> The possibility that users change the signal mask? Signal mask is not
> part of Modula-3. I think a programmer who messes with the signal mask
> shouldn't expect Modula-3 to restore it for him when it switches threads,
> processes exceptions, etc.
>
> If you want to provide hooks for it that would be nice but I think it's
> strictly optional.
>
> "Correctness" should (as always) mean correctness w.r.t. the Green Book,
> which makes no mention at all of signals... It does mention FloatMode
> however (page 75).
>
> Mika
>
> Tony Hosking writes:
>>
>>--Apple-Mail-78-848772270
>>Content-Transfer-Encoding: quoted-printable
>>Content-Type: text/plain;
>> charset=us-ascii
>>
>>I think we can argue that a programmer should program around this using =
>>TRY...FINALLY (i.e., even if they used FloatMode).
>>
>>So, I think we are safe with jmpbuf instead of sigjmpbuf.
>>
>>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 8 May 2010, at 18:56, Jay K wrote:
>>
>>>=20
>>> Is "proper" saving/restoring as much as we can think of, or is it =
>>fast, or is it matching Ada and C++, or .. ?
>>> Ada and C++ (gnat and g++) have often/historically used =
>>setjmp/longjmp.
>>> configure -enable-sjlj-exceptions
>>> It might be interesting to see if they try to avoid the signal mask =
>>versions when they use setjmp/longjmp.
>>> Lately they use table-based unwinding on platforms that they can -- =
>>which is to say, I *really* doubt
>>> they save/restore the signal mask, but they might.
>>>=20
>>>=20
>>> - Jay
>>>=20
>>> ----------------------------------------
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sat, 8 May 2010 18:51:18 -0400
>>>> CC: jkrell at elego.de; m3commit at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>=20
>>>>=20
>>>>=20
>>>> On 8 May 2010, at 18:38, Jay K wrote:
>>>>=20
>>>>> Or, understood, you really think we might throw around a signal mask =
>>change?
>>>>=20
>>>> It's possible.
>>>>=20
>>>>> Realize also that sigsetjmp or setjmp, whichever we use, is called =
>>incredibly often, and sigsetjmp is likely
>>>>> much much slower. Also notice..this I'll have to check...have we =
>>ever called sigsetjmp?
>>>>> Well, no, I doubt it. But maybe setjmp vs. _setjmp.
>>>>> Again though, this can be significantly slow.
>>>>>=20
>>>>>=20
>>>>> Ultimately as well...see..I started this email without a firm =
>>opinion, but now I'm "firming" toward the change I made.
>>>>> Consider C++ exceptions. Consider libunwind. Consider the SPARC =
>>stack walker (which I have to look at).
>>>>> Do they save/restore signal masks? I doubt it. Maybe. We can look =
>>into it. But I doubt it.
>>>>=20
>>>> We should confirm.
>>>>=20
>>>>> Raising an exception can indeed by slow. But entering a function =
>>with finally (or destructors) should not be overly so.
>>>>=20
>>>> Ultimately, we should use proper stack unwinding wherever possible.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> - Jay
>>>>>=20
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Sat, 8 May 2010 18:28:36 -0400
>>>>>> To: jkrell at elego.de
>>>>>> CC: m3commit at elegosoft.com
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>=20
>>>>>> Ah, now I remember. sigjmpbuf is important for unwinding on =
>>exception to make sure that if we unwind through a frame where the =
>>programmer changed the signal mask that we also restore the signal mask =
>>of the caller. I think you also probably break things like FloatMode by =
>>not restoring the signal mask properly.
>>>>>>=20
>>>>>> On 9 May 2010, at 00:09, Jay Krell wrote:
>>>>>>=20
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: jkrell at birch. 10/05/09 00:09:58
>>>>>>>=20
>>>>>>> Modified files:
>>>>>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3
>>>>>>>=20
>>>>>>> Log message:
>>>>>>> add SPARC32_SOLARIS
>>>>>>>=20
>>>>>>> correct jmpbuf sizes for I386_SOLARIS, AMD64_SOLARIS
>>>>>>> notice again that jmpbuf is much much smaller than sigjmpbuf,
>>>>>>> and this is jmpbuf; specifically:
>>>>>>> I386_SOLARIS jmpbuf 40 bytes with 4 align
>>>>>>> AMD64_SOLARIS jmpbuf 64 bytes with 8 align
>>>>>>> I386_SOLARIS sigjmpbuf 512 bytes with 4 align
>>>>>>> AMD64_SOLARIS sigjmpbuf 1024 bytes with 8 align
>>>>>>>=20
>>>>>>> remove some level of heap allocation of calling conventions
>>>>>>>=20
>>>>>>> accept all calling conventions for all targets
>>>>>>> Only NT386 has calling conventions, and it *highly* likely
>>>>>>> the only target ever to have them, therefore the mechanism
>>>>>>> does not need to be further generalized. (MIPS32 has two
>>>>>>> ABIs, but those will probably be two targets)
>>>>>>> This might let us save some unnecessary forking of *.i3 files.
>>>>>>> The initialization here can be further streamlined.
>>>>>>>=20
>>>>>>> shrink SOLgnu/SOLsun from sigjmpbuf to jmpbuf
>>>>>>> I'm not sure we use this though since we have a stack walker.
>>>>>>> fix SPARC64_SOLARIS too to be smaller
>>>>>>>=20
>>>>>>> SPARC32_SOLARIS
>>>>>>> jmpbuf size: 48
>>>>>>> sigjmpbuf size: 76
>>>>>>> alignment: 4 4
>>>>>>>=20
>>>>>>> SPARC64_SOLARIS
>>>>>>> jmpbuf size: 96
>>>>>>> sigjmpbuf size: 152
>>>>>>> alignment: 8 8
>>>>>>=20
>>>>>=20
>>>>=20
>>> =20
>>
>>
>>--Apple-Mail-78-848772270
>>Content-Transfer-Encoding: quoted-printable
>>Content-Type: text/html;
>> charset=us-ascii
>>
>>>>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I =
>>think we can argue that a programmer should program around this using =
>>TRY...FINALLY (i.e., even if they used =
>>FloatMode).
So, I think we are safe with jmpbuf =
>>instead of sigjmpbuf.


>>>>color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
>>auto; text-indent: 0px; text-transform: none; white-space: normal; =
>>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>>-webkit-border-vertical-spacing: 0px; =
>>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>>auto; -webkit-text-stroke-width: 0; ">>>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>>font-family: Helvetica; font-size: 12px; font-style: normal; =
>>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>>line-height: normal; -webkit-text-decorations-in-effect: none; =
>>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">>>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>>-webkit-line-break: after-white-space; ">>>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>>font-family: Helvetica; font-size: 12px; font-style: normal; =
>>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>>line-height: normal; -webkit-text-decorations-in-effect: none; =
>>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" color=3D"#0000FF">>>class=3D"Apple-style-span" face=3D"Gill Sans">>>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>>'Gill Sans'; ">>>0, 255); font-family: 'Gill Sans'; ">Antony =
>>Hosking>>face=3D"Gill Sans">>>'Gill Sans'; ">>>'Gill Sans'; ">?|>>class=3D"Apple-converted-space">?>>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; ">>>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; =
>>">Associate Professor>>style=3D"font-family: 'Gill Sans'; ">>>style=3D"font-family: 'Gill Sans'; ">?| Computer Science | Purdue =
>>University>> face=3D"GillSans-Light">>>style=3D"font-family: GillSans-Light; ">305 N. University Street | West =
>>Lafayette | IN 47907 | USA>>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans">>>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>>'Gill Sans'; ">>>0, 255); font-family: 'Gill Sans'; ">Office>>class=3D"Apple-style-span" face=3D"GillSans-Light">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; =
>>">?+1 765 494 6001 |>>class=3D"Apple-converted-space">?>>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans">>>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>>'Gill Sans'; ">>>0, 255); font-family: 'Gill Sans'; ">Mobile>>class=3D"Apple-style-span" face=3D"GillSans-Light">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">>>class=3D"Apple-converted-space">?+1 765 427 =
>>5484>>face=3D"GillSans-Light">
>>class=3D"khtml-block-placeholder">
>>>
>>class=3D"Apple-interchange-newline">
>>class=3D"Apple-interchange-newline">
>>
>>
On 8 May 2010, at 18:56, Jay K wrote:
>>class=3D"Apple-interchange-newline">
Is =
>>"proper" saving/restoring as much as we can think of, or is it fast, or =
>>is it matching Ada and C++, or .. ?
Ada and C++ (gnat and g++) have =
>>often/historically used setjmp/longjmp.
? configure =
>>-enable-sjlj-exceptions
It might be interesting to see if they try to =
>>avoid the signal mask versions when they use setjmp/longjmp.
Lately =
>>they use table-based unwinding on platforms that they can -- which is to =
>>say, I *really* doubt
they save/restore the signal mask, but they =
>>might.


?- =
>>Jay

----------------------------------------
>>type=3D"cite">Subject: Re: [M3commit] CVS Update: =
>>cm3
From:>>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu

>>quote>Date: Sat, 8 May 2010 18:51:18 =
>>-0400
CC:>>href=3D"mailto:jkrell at elego.de">jkrell at elego.de;>>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com

>>ckquote>To:>>href=3D"mailto:jay.krell at cornell.edu">jay.krell at cornell.edu

>>quote>
>>type=3D"cite">
>>type=3D"cite">
On 8 May 2010, =
>>at 18:38, Jay K wrote:
>>type=3D"cite">
>>type=3D"cite">Or, understood, you really think we might throw around a =
>>signal mask change?
>>type=3D"cite">
It's =
>>possible.
>>type=3D"cite">
>>type=3D"cite">Realize also that sigsetjmp or setjmp, whichever we use, =
>>is called incredibly often, and sigsetjmp is =
>>likely
>>type=3D"cite">much much slower. Also notice..this I'll have to =
>>check...have we ever called =
>>sigsetjmp?
>>type=3D"cite">Well, no, I doubt it. But maybe =
>>setjmp vs. _setjmp.
>>type=3D"cite">Again though, this can be =
>>significantly slow.
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">Ultimately as well...see..I =
>>started this email without a firm opinion, but now I'm "firming" toward =
>>the change I made.
>>type=3D"cite">Consider C++ exceptions. =
>>Consider libunwind. Consider the SPARC stack walker (which I have to =
>>look at).
>>type=3D"cite">Do they save/restore signal =
>>masks? I doubt it. Maybe. We can look into it. But I doubt =
>>it.
>>type=3D"cite">
We should =
>>confirm.
>>type=3D"cite">
>>type=3D"cite">Raising an exception can indeed by slow. But entering a =
>>function with finally (or destructors) should not be overly =
>>so.
>>type=3D"cite">
Ultimately, we =
>>should use proper stack unwinding wherever =
>>possible.
>>type=3D"cite">
>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">- =
>>Jay
>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">----------------------------------------

>>lockquote>>>type=3D"cite">From:>>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu

>>quote>>>type=3D"cite">Date: Sat, 8 May 2010 18:28:36 =
>>-0400
>>type=3D"cite">To:>>href=3D"mailto:jkrell at elego.de">jkrell at elego.de

>>kquote>>>type=3D"cite">CC:>>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com

>>ckquote>>>type=3D"cite">Subject: Re: [M3commit] CVS =
>>Update: cm3
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">Ah, =
>>now I remember. sigjmpbuf is important for unwinding on exception to =
>>make sure that if we unwind through a frame where the programmer changed =
>>the signal mask that we also restore the signal mask of the caller. I =
>>think you also probably break things like FloatMode by not restoring the =
>>signal mask =
>>properly.
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">On 9 =
>>May 2010, at 00:09, Jay Krell =
>>wrote:
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">CVSROOT: =
>>/usr/cvs

>>e type=3D"cite">>>type=3D"cite">Changes by: jkrell at birch. =
>>10/05/09 =
>>00:09:58

>>e type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">Modified =
>>files:
>>type=3D"cite">>>type=3D"cite">cm3/m3-sys/m3middle/src/: =
>>Target.i3 =
>>Target.m3

>>te type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">Log =
>>message:

>>e type=3D"cite">>>type=3D"cite">add =
>>SPARC32_SOLARIS

>>ockquote type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">correct jmpbuf sizes for =
>>I386_SOLARIS, =
>>AMD64_SOLARIS

>>kquote type=3D"cite">>>type=3D"cite">notice again that jmpbuf is much =
>>much smaller than =
>>sigjmpbuf,

>>ote type=3D"cite">>>type=3D"cite">and this is jmpbuf; =
>>specifically:

>>kquote type=3D"cite">>>type=3D"cite">I386_SOLARIS jmpbuf 40 bytes =
>>with 4 =
>>align
>>type=3D"cite">>>type=3D"cite">AMD64_SOLARIS jmpbuf 64 bytes =
>>with 8 =
>>align
>>type=3D"cite">>>type=3D"cite">I386_SOLARIS sigjmpbuf 512 bytes =
>>with 4 =
>>align
>>type=3D"cite">>>type=3D"cite">AMD64_SOLARIS sigjmpbuf 1024 =
>>bytes with 8 =
>>align
>>type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">remove some level of heap =
>>allocation of calling =
>>conventions

>>uote type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">accept all calling conventions =
>>for all =
>>targets

>> type=3D"cite">>>type=3D"cite">Only NT386 has calling =
>>conventions, and it *highly* =
>>likely
>>type=3D"cite">>>type=3D"cite">the only target ever to have =
>>them, therefore the =
>>mechanism

>>te type=3D"cite">>>type=3D"cite">does not need to be further =
>>generalized. (MIPS32 has =
>>two
>>type=3D"cite">>>type=3D"cite">ABIs, but those will probably be =
>>two =
>>targets)

>>e type=3D"cite">>>type=3D"cite">This might let us save some =
>>unnecessary forking of *.i3 =
>>files.
>>type=3D"cite">>>type=3D"cite">The initialization here can be =
>>further =
>>streamlined.

>>quote type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">shrink SOLgnu/SOLsun from =
>>sigjmpbuf to =
>>jmpbuf
>>type=3D"cite">>>type=3D"cite">I'm not sure we use this though =
>>since we have a stack =
>>walker.

>> type=3D"cite">>>type=3D"cite">fix SPARC64_SOLARIS too to be =
>>smaller

>> type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">>>type=3D"cite">SPARC32_SOLARIS
>>blockquote>
>> type=3D"cite">jmpbuf size: =
>>48
>>type=3D"cite">>>type=3D"cite">sigjmpbuf size: =
>>76
>>type=3D"cite">>>type=3D"cite">alignment: 4 =
>>4
>>type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">>>type=3D"cite">SPARC64_SOLARIS
>>blockquote>
>> type=3D"cite">jmpbuf size: =
>>96
>>type=3D"cite">>>type=3D"cite">sigjmpbuf size: =
>>152
>>type=3D"cite">>>type=3D"cite">alignment: 8 =
>>8
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">
>>style=3D"white-space:pre">>>style=3D"white-space:pre"> >>style=3D"white-space:pre">  ??>>class=3D"Apple-tab-span" style=3D"white-space:pre">>>class=3D"Apple-tab-span" style=3D"white-space:pre">  =
>>?

=
>>
>>--Apple-Mail-78-848772270--
 		 	   		  

From jay.krell at cornell.edu  Sun May  9 01:54:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 23:54:49 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>,
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>,
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
Message-ID: <COL101-W2850411CE9F0D7659AA965E6F70@phx.gbl>


>> but on the other, we don't have a good debugger story anyway.
>
> m3gdb works well on certain platforms.


?I don't want to build m3gdb.
?It doesn't work on all platforms.
?gdb should suffice.
? Must parameters/locals really have gibberish names and can we really not
? represent the types in a manner that gdb understands?
?We need CodeView information on Windows.
At least I figured out that Debian 4.0 was part of the problem, fixed in Debian 5.0.
? (I didn't realize I was still running 4.0! I've upgraded since.)

?- Jay
 		 	   		  

From mika at async.async.caltech.edu  Sun May  9 01:55:53 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 08 May 2010 16:55:53 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W487024C8B81D4B8120C348E6F70@phx.gbl> 
References: <20100508220958.8EA242474003@birch.elegosoft.com>, ,
	<62B45315-F33E-4586-BCCE-CE57F5E307EA@cs.purdue.edu>,
	<COL101-W455DE8BD33138D220620E6E6F70@phx.gbl>, ,
	<C7985D61-0C4C-44B8-ACBE-2548725E3153@cs.purdue.edu>,
	<COL101-W94565E47A143953025584E6F70@phx.gbl>,
	<6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu>,
	<20100508234309.937D21A2095@async.async.caltech.edu>
	<COL101-W487024C8B81D4B8120C348E6F70@phx.gbl>
Message-ID: <20100508235553.70BB41A2097@async.async.caltech.edu>

Jay K writes:
>
>It's not a closed system. Modula-3 can call C can call C++ can call Modula-=
>3=2C etc.=2C and they can call raise exceptions.
>I'm not sure what the C exception story is on all platforms=2C but at least=
> on Windows there is RaiseException.
>
>Green book doesn't mention m3-libs/m3core/src/Unix=2C but it exists anyway.
>
>=A0- Jay

Well the fact that there is no specification means there's no definition
of what behavior is "correct."  I think it's up to the user of the 
primitives to ensure he's not breaking anything, if it's not defined 
in the Book.

Surely the way to deal with it is to make the user simply guarantee
that whatever C routines he calls will in fact conform with Modula-3's
parameter passing and exception behavior.  

So it would be nice to document how one goes about writing a C program
so that it conforms with (a particular implementation of) Modula-3's
conventions.  But changing the signal mask?  Maybe such a programmer
shouldn't be programming in Modula-3, not if his demands on M3 cause
things to slow down significantly for users who are writing their code
mostly in Modula-3.  (As far as I know there's no real reason to write
your code in C if you can use Modula-3, not sure about C++.)

    Mika


From rcolebur at SCIRES.COM  Sun May  9 03:14:53 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 8 May 2010 21:14:53 -0400
Subject: [M3devel] m3core broken on Usocket.c in HEAD
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C1895B4B@ATLEX02-SRV.SCIRES.LOCAL>

I am noticing that Usocket.c in m3-libs\m3core fails to compile on Windows.
This is from the HEAD branch.
Regards,
Randy

________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100508/971abbb4/attachment-0001.html>

From peter.mckinna at gmail.com  Sun May  9 13:51:05 2010
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 9 May 2010 21:51:05 +1000
Subject: [M3devel] Compile Options
In-Reply-To: <C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
	<C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>
Message-ID: <j2t3d9e5afc1005090451x1ffbc3a1x664ce53571d300e2@mail.gmail.com>

Sorry should have mentioned AMD_64 linux.  I was trying to check if the code
generator was screwing up and every time I made a slight change the stabs
were completely different in the 2 ms files from the same module. In fact
the generated code was so completely different for just 2 lines of M3 I
found it incomprehensible. I tried to turn off the debugging to reduce the
clutter. So then I played around with some of the other compile time
switches and found some problems. This is in version 5.8.4

Regards
Peter

On Sat, May 8, 2010 at 2:55 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:

> What target platform?
>
> On 8 May 2010, at 00:22, Peter McKinna wrote:
>
> > Hey,
> >
> >   Using -c to disable library or program generation does not seem to
> work. Also how do you turn off debug symbol generation?
> > And the -O switch doesnt seem to optimise anything.
> >
> >   Is it just me or the documentation.
> >
> > Regards
> >
> > Peter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100509/7020fda3/attachment-0001.html>

From jay.krell at cornell.edu  Sun May  9 14:44:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 9 May 2010 12:44:26 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <j2t3d9e5afc1005090451x1ffbc3a1x664ce53571d300e2@mail.gmail.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>,
	<C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>,
	<j2t3d9e5afc1005090451x1ffbc3a1x664ce53571d300e2@mail.gmail.com>
Message-ID: <COL101-W178E2932A99B8781F0FE6CE6F80@phx.gbl>


aha, good reason to disable debugging.

I think this has been broken a very long time -- the usage says debugging is the default,
and that is true..and I see no way to disable it..

Either we need like -g0 or the default should be no symbols.
??

You can also hack the config files -- remove any -g(stabs)(+).
? An ok option for your immediate purposes, if not the right general solution for everyone.


I forgot to mention in my commit comment: I did go ahead with the m3back_debug, m3back_optimize switches.
It should be you just set m3back_debug = "" in the toplevel config (or maybe with -D on the command line?) no symbols.

Also more subtly I changed optimizing from -O3 to -O2 -Wuninitialized.
Maybe should leave that alone..as I almost never use it either way.


?- Jay

________________________________
> Date: Sun, 9 May 2010 21:51:05 +1000
> From: peter.mckinna at gmail.com
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compile Options
>
> Sorry should have mentioned AMD_64 linux. I was trying to check if the code generator was screwing up and every time I made a slight change the stabs were completely different in the 2 ms files from the same module. In fact the generated code was so completely different for just 2 lines of M3 I found it incomprehensible. I tried to turn off the debugging to reduce the clutter. So then I played around with some of the other compile time switches and found some problems. This is in version 5.8.4
>
>
> Regards
> Peter
>
> On Sat, May 8, 2010 at 2:55 PM, Tony Hosking> wrote:
>
> What target platform?
>
>
>
> On 8 May 2010, at 00:22, Peter McKinna wrote:
>
>
>
>> Hey,
>
>>
>
>> Using -c to disable library or program generation does not seem to work. Also how do you turn off debug symbol generation?
>
>> And the -O switch doesnt seem to optimise anything.
>
>>
>
>> Is it just me or the documentation.
>
>>
>
>> Regards
>
>>
>
>> Peter
>
>
>
>
 		 	   		  

From wagner at elegosoft.com  Mon May 10 10:26:41 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 10 May 2010 10:26:41 +0200
Subject: [M3devel] builds on release branch broken
Message-ID: <20100510102641.ab1etdvcgs4s0oos@mail.elegosoft.com>

I just noticed several build failures on the release branch.
One seems to be caused by this:

=== package m3-sys/m3middle ===
  +++ cm3 -build  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'  
-DCM3_LAST_CHANGED='2010-04-11'  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'  
-DCM3LASTCHANGED='2010-04-11' $RARGS  && cm3 -ship $RARGS  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'  
-DCM3_LAST_CHANGED='2010-04-11'  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'  
-DCM3LASTCHANGED='2010-04-11'  +++
gcc: ../src/POSIX/CoffTime.c: No such file or directory
gcc: No input files specified
   compile_c => 1
C compiler failed compiling: ../src/POSIX/CoffTime.c
gcc: ../src/POSIX/CoffTime.c: No such file or directory
gcc: No input files specified
   compile_c => 1
C compiler failed compiling: ../src/POSIX/CoffTime.c
retry build after cleaning

See http://hudson.modula3.com:8080/job/cm3-build-AMD64_FREEBSD/104/, too.

One of these commits seems to be the culprit:

Changes

    1. move _DARWIN_FEATURE_64_ONLY_BIT_INODE earlier, so that it will work
       (This only affects ARM_DARWIN I believe, and maybe not even  
it.) (detail)
    2. copy from head so it compiles (detail)
    3. copy from head, so that release can be built by "upgrading" from head
       (head m3core has cut down/removed Utime for portability, and it
       was used here)) (detail)
    4. whitespace only (detail)

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  Mon May 10 10:38:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 10 May 2010 08:38:44 +0000
Subject: [M3devel] builds on release branch broken
In-Reply-To: <20100510102641.ab1etdvcgs4s0oos@mail.elegosoft.com>
References: <20100510102641.ab1etdvcgs4s0oos@mail.elegosoft.com>
Message-ID: <COL101-W7420AE3AB05362E9C432FE6F90@phx.gbl>


understood, I'll fix shortly

?- Jay


----------------------------------------
> Date: Mon, 10 May 2010 10:26:41 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] builds on release branch broken
>
> I just noticed several build failures on the release branch.
> One seems to be caused by this:
>
> === package m3-sys/m3middle ===
> +++ cm3 -build
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'
> -DCM3_LAST_CHANGED='2010-04-11'
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'
> -DCM3LASTCHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'
> -DCM3_LAST_CHANGED='2010-04-11'
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'
> -DCM3LASTCHANGED='2010-04-11' +++
> gcc: ../src/POSIX/CoffTime.c: No such file or directory
> gcc: No input files specified
> compile_c => 1
> C compiler failed compiling: ../src/POSIX/CoffTime.c
> gcc: ../src/POSIX/CoffTime.c: No such file or directory
> gcc: No input files specified
> compile_c => 1
> C compiler failed compiling: ../src/POSIX/CoffTime.c
> retry build after cleaning
>
> See http://hudson.modula3.com:8080/job/cm3-build-AMD64_FREEBSD/104/, too.
>
> One of these commits seems to be the culprit:
>
> Changes
>
> 1. move _DARWIN_FEATURE_64_ONLY_BIT_INODE earlier, so that it will work
> (This only affects ARM_DARWIN I believe, and maybe not even
> it.) (detail)
> 2. copy from head so it compiles (detail)
> 3. copy from head, so that release can be built by "upgrading" from head
> (head m3core has cut down/removed Utime for portability, and it
> was used here)) (detail)
> 4. whitespace only (detail)
>
> 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  Mon May 10 11:37:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 10 May 2010 09:37:21 +0000
Subject: [M3devel] program vs. Program
Message-ID: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>


Despite the length of this email, I don't think this is a big deal..


With the "origin/runpath" changes from a while ago, "program" "doesn't work", unless build_standalone.
At least on most systems. That is, you can't run the binary from its shipped location, in pkg.


We should consider: 
?- make program imply build_standalone? 
?- never ship "program" -- not runable within the package store? 
?- drop in wrapper .sh files that set/append LD_LIBRARY_PATH? 
?- maybe the scheme I alluded to, which I'm pretty sure libtool implements sometimes, where you use full paths on the initial link, an then "ship/install" relink first, either with new full paths or with $ORIGIN.


An exception would be, like, how gcc uses libexec/cc1.
?If something in bin calls out to something in pkg, and either the file in pkg is build_standalone, or, well $ORIGIN sometimes
?is relative to the executable -- like on Mac OSX 10.4 with @executable_path, but this is probably too rare to consider.
And even if we have "private" executables in "pkg", build_standalone is still wasteful.


So we'd want to look through stuff like:


jbook2:cm3 jay$ grep ^program `find . | grep /m3makefile$` | grep -v examples | grep -v test
./caltech-parser/hack/src/m3makefile:program("dummy")
./doc/tutorial/ui/script/m3makefile:program ("script")
./m3-comm/tapi/src/m3makefile:program ("foo2")
./m3-db/db/demo/m3makefile:program("demo")
./m3-db/db/src/postgresql/demo/m3makefile:program("demo")
./m3-db/stable/example/src/m3makefile:program("example")
./m3-demo/sharedboard/boardclient/src/m3makefile:program ("boardclient")
./m3-demo/sharedboard/boardserver/src/m3makefile:program ("boardserver")
./m3-demo/sharedboard/calendar/src/m3makefile:program ("calendar")
./m3-libs/digraph/src/m3makefile:program(DiGraphTest)
./m3-libs/digraph/src/m3makefile:program(TopSortTest)
./m3-libs/synthesizer/example/chirp/src/m3makefile:program("chirp")
./m3-libs/synthesizer/example/echo/src/m3makefile:program("echo")
./m3-libs/synthesizer/example/entchen/src/m3makefile:program("entchen")
./m3-libs/synthesizer/example/filter/src/m3makefile:program("filter")
./m3-libs/synthesizer/example/inout/src/m3makefile:program("inout")
./m3-libs/synthesizer/example/oscillator/src/m3makefile:program("oscillator")
./m3-libs/synthesizer/example/plot/src/m3makefile:program("plot")
./m3-libs/synthesizer/example/rueckwaerts/src/m3makefile:program("rueckwaerts")
./m3-libs/synthesizer/example/sirene/src/m3makefile:program("sirene")
./m3-libs/synthesizer/example/stereo/src/m3makefile:program("stereo")
./m3-libs/synthesizer/example/stream/src/m3makefile:program("stream")
./m3-libs/wellfett/example/src/m3makefile:program("example")
./m3-pkgtools/pkgfprint/src/m3makefile:program("pkgfp")
./m3-pkgtools/pkgq/src/m3makefile:program("pkgq")
./m3-pkgtools/pkgsrv/src/m3makefile:program("packageserver")
./m3-pkgtools/pkgtool/src/m3makefile:program("packagetool")
./m3-sys/cm3/src/m3makefile:program ("cm3")
./m3-sys/cminstall/src/m3makefile:program ("cminstall")
./m3-sys/dll2lib/src/m3makefile:program ("dll2lib")
./m3-sys/libdump/src/m3makefile:program ("libdump")
./m3-sys/m3cgcat/src/m3makefile:program ("m3cgcat")
./m3-sys/m3cggen/src/m3makefile:program ("m3cggen")
./m3-sys/m3staloneback/src/m3makefile:program ("m3back")
./m3-tools/cmpfp/src/m3makefile:program ("cmpfp")
./m3-tools/cvsup/cvpasswd/src/m3makefile:program("cvpasswd")
./m3-tools/macapi/src/m3makefile:program("macapi")
./m3-ui/juno-2/juno-app/pkl-fonts/src/m3makefile:program??? ??? ("PklFonts")
./m3-ui/juno-2/juno-machine/linear/src/m3makefile:program("LinearTest")
./m3-ui/juno-2/juno-machine/nonlinear/src/m3makefile:program??? ??? ("NonLinearTest")
./m3-ui/juno-2/juno-machine/runtime/src/m3makefile:program??? ??? ("RuntimeTest")
./m3-ui/juno-2/juno-machine/solve/src/m3makefile:program??? ??? ("SolveTest")


At a quick glance, a lot can be ignored. Anything without quotes doesn't curently build.
m3-pkgtools doesn't currently build.
cm3 and cminstall are "special" -- and still, we shouldn't bother putting them in pkg.
m3back is never used; m3ccgen is standalone and rarely used
libdump I think is unused; dll2lib is unused.
This doesn't check if things are build_standalone, e.g. PklFonts.


?- Jay


 		 	   		  

From hosking at cs.purdue.edu  Mon May 10 15:42:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 10 May 2010 09:42:12 -0400
Subject: [M3devel] program vs. Program
In-Reply-To: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>
References: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>
Message-ID: <358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>

program is not supposed to ship anything, right?

Only Program should do that.

On 10 May 2010, at 05:37, Jay K wrote:

> 
> Despite the length of this email, I don't think this is a big deal..
> 
> 
> With the "origin/runpath" changes from a while ago, "program" "doesn't work", unless build_standalone.
> At least on most systems. That is, you can't run the binary from its shipped location, in pkg.
> 
> 
> We should consider: 
>  - make program imply build_standalone? 
>  - never ship "program" -- not runable within the package store  
>  - drop in wrapper .sh files that set/append LD_LIBRARY_PATH? 
>  - maybe the scheme I alluded to, which I'm pretty sure libtool implements sometimes, where you use full paths on the initial link, an then "ship/install" relink first, either with new full paths or with $ORIGIN.
> 
> 
> An exception would be, like, how gcc uses libexec/cc1.
>  If something in bin calls out to something in pkg, and either the file in pkg is build_standalone, or, well $ORIGIN sometimes
>  is relative to the executable -- like on Mac OSX 10.4 with @executable_path, but this is probably too rare to consider.
> And even if we have "private" executables in "pkg", build_standalone is still wasteful.
> 
> 
> So we'd want to look through stuff like:
> 
> 
> jbook2:cm3 jay$ grep ^program `find . | grep /m3makefile$` | grep -v examples | grep -v test
> ./caltech-parser/hack/src/m3makefile:program("dummy")
> ./doc/tutorial/ui/script/m3makefile:program ("script")
> ./m3-comm/tapi/src/m3makefile:program ("foo2")
> ./m3-db/db/demo/m3makefile:program("demo")
> ./m3-db/db/src/postgresql/demo/m3makefile:program("demo")
> ./m3-db/stable/example/src/m3makefile:program("example")
> ./m3-demo/sharedboard/boardclient/src/m3makefile:program ("boardclient")
> ./m3-demo/sharedboard/boardserver/src/m3makefile:program ("boardserver")
> ./m3-demo/sharedboard/calendar/src/m3makefile:program ("calendar")
> ./m3-libs/digraph/src/m3makefile:program(DiGraphTest)
> ./m3-libs/digraph/src/m3makefile:program(TopSortTest)
> ./m3-libs/synthesizer/example/chirp/src/m3makefile:program("chirp")
> ./m3-libs/synthesizer/example/echo/src/m3makefile:program("echo")
> ./m3-libs/synthesizer/example/entchen/src/m3makefile:program("entchen")
> ./m3-libs/synthesizer/example/filter/src/m3makefile:program("filter")
> ./m3-libs/synthesizer/example/inout/src/m3makefile:program("inout")
> ./m3-libs/synthesizer/example/oscillator/src/m3makefile:program("oscillator")
> ./m3-libs/synthesizer/example/plot/src/m3makefile:program("plot")
> ./m3-libs/synthesizer/example/rueckwaerts/src/m3makefile:program("rueckwaerts")
> ./m3-libs/synthesizer/example/sirene/src/m3makefile:program("sirene")
> ./m3-libs/synthesizer/example/stereo/src/m3makefile:program("stereo")
> ./m3-libs/synthesizer/example/stream/src/m3makefile:program("stream")
> ./m3-libs/wellfett/example/src/m3makefile:program("example")
> ./m3-pkgtools/pkgfprint/src/m3makefile:program("pkgfp")
> ./m3-pkgtools/pkgq/src/m3makefile:program("pkgq")
> ./m3-pkgtools/pkgsrv/src/m3makefile:program("packageserver")
> ./m3-pkgtools/pkgtool/src/m3makefile:program("packagetool")
> ./m3-sys/cm3/src/m3makefile:program ("cm3")
> ./m3-sys/cminstall/src/m3makefile:program ("cminstall")
> ./m3-sys/dll2lib/src/m3makefile:program ("dll2lib")
> ./m3-sys/libdump/src/m3makefile:program ("libdump")
> ./m3-sys/m3cgcat/src/m3makefile:program ("m3cgcat")
> ./m3-sys/m3cggen/src/m3makefile:program ("m3cggen")
> ./m3-sys/m3staloneback/src/m3makefile:program ("m3back")
> ./m3-tools/cmpfp/src/m3makefile:program ("cmpfp")
> ./m3-tools/cvsup/cvpasswd/src/m3makefile:program("cvpasswd")
> ./m3-tools/macapi/src/m3makefile:program("macapi")
> ./m3-ui/juno-2/juno-app/pkl-fonts/src/m3makefile:program        ("PklFonts")
> ./m3-ui/juno-2/juno-machine/linear/src/m3makefile:program("LinearTest")
> ./m3-ui/juno-2/juno-machine/nonlinear/src/m3makefile:program        ("NonLinearTest")
> ./m3-ui/juno-2/juno-machine/runtime/src/m3makefile:program        ("RuntimeTest")
> ./m3-ui/juno-2/juno-machine/solve/src/m3makefile:program        ("SolveTest")
> 
> 
> At a quick glance, a lot can be ignored. Anything without quotes doesn't curently build.
> m3-pkgtools doesn't currently build.
> cm3 and cminstall are "special" -- and still, we shouldn't bother putting them in pkg.
> m3back is never used; m3ccgen is standalone and rarely used
> libdump I think is unused; dll2lib is unused.
> This doesn't check if things are build_standalone, e.g. PklFonts.
> 
> 
>  - Jay
> 
> 
> 		 	   		  



From wagner at elegosoft.com  Mon May 10 17:40:15 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 10 May 2010 17:40:15 +0200
Subject: [M3devel] program vs. Program
In-Reply-To: <358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>
References: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>
	<358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>
Message-ID: <20100510174015.0s21r39i68ck80sc@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> program is not supposed to ship anything, right?

program ships to the /pkg/TARGET directory, while
Program shipts to /bin.

> Only Program should do that.
>
> On 10 May 2010, at 05:37, Jay K wrote:
>
>> Despite the length of this email, I don't think this is a big deal..
>>
>> With the "origin/runpath" changes from a while ago, "program"   
>> "doesn't work", unless build_standalone.
>> At least on most systems. That is, you can't run the binary from   
>> its shipped location, in pkg.
>>
>> We should consider:
>>  - make program imply build_standalone?

Probably simplest solution, but not really what I would expect.

>>  - never ship "program" -- not runable within the package store

Would be a non-compatible change.

>>  - drop in wrapper .sh files that set/append LD_LIBRARY_PATH?

Strange.

>>  - maybe the scheme I alluded to, which I'm pretty sure libtool   
>> implements sometimes, where you use full paths on the initial link,  
>>  an then "ship/install" relink first, either with new full paths or  
>>  with $ORIGIN.

Why not use the correct paths via $ORIGIN? For program they are
of course different than for Program. Too difficult?

Not yet sure what we should do,

Olaf


>>
>>
>> An exception would be, like, how gcc uses libexec/cc1.
>>  If something in bin calls out to something in pkg, and either the   
>> file in pkg is build_standalone, or, well $ORIGIN sometimes
>>  is relative to the executable -- like on Mac OSX 10.4 with   
>> @executable_path, but this is probably too rare to consider.
>> And even if we have "private" executables in "pkg",   
>> build_standalone is still wasteful.
>>
>>
>> So we'd want to look through stuff like:
>>
>>
>> jbook2:cm3 jay$ grep ^program `find . | grep /m3makefile$` | grep   
>> -v examples | grep -v test
>> ./caltech-parser/hack/src/m3makefile:program("dummy")
>> ./doc/tutorial/ui/script/m3makefile:program ("script")
>> ./m3-comm/tapi/src/m3makefile:program ("foo2")
>> ./m3-db/db/demo/m3makefile:program("demo")
>> ./m3-db/db/src/postgresql/demo/m3makefile:program("demo")
>> ./m3-db/stable/example/src/m3makefile:program("example")
>> ./m3-demo/sharedboard/boardclient/src/m3makefile:program ("boardclient")
>> ./m3-demo/sharedboard/boardserver/src/m3makefile:program ("boardserver")
>> ./m3-demo/sharedboard/calendar/src/m3makefile:program ("calendar")
>> ./m3-libs/digraph/src/m3makefile:program(DiGraphTest)
>> ./m3-libs/digraph/src/m3makefile:program(TopSortTest)
>> ./m3-libs/synthesizer/example/chirp/src/m3makefile:program("chirp")
>> ./m3-libs/synthesizer/example/echo/src/m3makefile:program("echo")
>> ./m3-libs/synthesizer/example/entchen/src/m3makefile:program("entchen")
>> ./m3-libs/synthesizer/example/filter/src/m3makefile:program("filter")
>> ./m3-libs/synthesizer/example/inout/src/m3makefile:program("inout")
>> ./m3-libs/synthesizer/example/oscillator/src/m3makefile:program("oscillator")
>> ./m3-libs/synthesizer/example/plot/src/m3makefile:program("plot")
>> ./m3-libs/synthesizer/example/rueckwaerts/src/m3makefile:program("rueckwaerts")
>> ./m3-libs/synthesizer/example/sirene/src/m3makefile:program("sirene")
>> ./m3-libs/synthesizer/example/stereo/src/m3makefile:program("stereo")
>> ./m3-libs/synthesizer/example/stream/src/m3makefile:program("stream")
>> ./m3-libs/wellfett/example/src/m3makefile:program("example")
>> ./m3-pkgtools/pkgfprint/src/m3makefile:program("pkgfp")
>> ./m3-pkgtools/pkgq/src/m3makefile:program("pkgq")
>> ./m3-pkgtools/pkgsrv/src/m3makefile:program("packageserver")
>> ./m3-pkgtools/pkgtool/src/m3makefile:program("packagetool")
>> ./m3-sys/cm3/src/m3makefile:program ("cm3")
>> ./m3-sys/cminstall/src/m3makefile:program ("cminstall")
>> ./m3-sys/dll2lib/src/m3makefile:program ("dll2lib")
>> ./m3-sys/libdump/src/m3makefile:program ("libdump")
>> ./m3-sys/m3cgcat/src/m3makefile:program ("m3cgcat")
>> ./m3-sys/m3cggen/src/m3makefile:program ("m3cggen")
>> ./m3-sys/m3staloneback/src/m3makefile:program ("m3back")
>> ./m3-tools/cmpfp/src/m3makefile:program ("cmpfp")
>> ./m3-tools/cvsup/cvpasswd/src/m3makefile:program("cvpasswd")
>> ./m3-tools/macapi/src/m3makefile:program("macapi")
>> ./m3-ui/juno-2/juno-app/pkl-fonts/src/m3makefile:program        ("PklFonts")
>> ./m3-ui/juno-2/juno-machine/linear/src/m3makefile:program("LinearTest")
>> ./m3-ui/juno-2/juno-machine/nonlinear/src/m3makefile:program         
>>  ("NonLinearTest")
>> ./m3-ui/juno-2/juno-machine/runtime/src/m3makefile:program          
>> ("RuntimeTest")
>> ./m3-ui/juno-2/juno-machine/solve/src/m3makefile:program          
>> ("SolveTest")
>>
>>
>> At a quick glance, a lot can be ignored. Anything without quotes   
>> doesn't curently build.
>> m3-pkgtools doesn't currently build.
>> cm3 and cminstall are "special" -- and still, we shouldn't bother   
>> putting them in pkg.
>> m3back is never used; m3ccgen is standalone and rarely used
>> libdump I think is unused; dll2lib is unused.
>> This doesn't check if things are build_standalone, e.g. PklFonts.
>>
>>
>>  - Jay
>>
>>
>>
>
>



-- 
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 rcolebur at SCIRES.COM  Mon May 10 21:19:39 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 10 May 2010 15:19:39 -0400
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20100509063527.854BC2474003@birch.elegosoft.com>
References: <20100509063527.854BC2474003@birch.elegosoft.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C1895CB6@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

I agree with some of your sentiments about the ugliness of the POSIX GUI, e.g. C & G buttons for close and grow, but I again want to point out that the "Win32" GUI is not ideal either.

Please recall that the changes made in the Win32 side were to make the Trestle/FormsVBT GUI appear more like Windows NT GUI at the time, but these are only approximations and it is not identical.  Plus, the Windows GUI continues to evolve, so the look and feel is now even further apart from the Windows Aero interface, than in 1995 when my company paid CMass to make the Win32 NT mods.  I haven't used X-Windows in a while, so not sure how far apart Trestle on X is from just X.

The other aspect that needs to be considered is that if the look/feel of the GUI changes, someone needs to update all the Trestle/FormsVBT documentation to match.  This may also create a cascade of documentation edits for any user programs/systems built and documented using the prior look and feel.

Note that the operation of scroll bars as documented under Trestle/FormsVBT are radically different from Microsoft Windows.  The current Win32 scroll bar implementation is closer to MS Windows, but it is still different, and it is not documented in Trestle/FormsVBT.  (I have a write-up on this I can provide.)

Depending on the needs/desires of the M3 community, there may be a need to maintain some runtime switch or compile time option to switch between the old style look and feel and any new style that is implemented.

Perhaps we should have a discussion in the m3devel forum to see how folks want to proceed before making any radical changes in the GUI look and feel.

Regards,
Randy

-----Original Message-----
From: Jay Krell [mailto:jkrell at elego.de]
Sent: Sunday, May 09, 2010 4:35 AM
To: m3commit at elegosoft.com
Subject: [M3commit] CVS Update: cm3

CVSROOT:        /usr/cvs
Changes by:     jkrell at birch.   10/05/09 08:35:27

Modified files:
        cm3/m3-ui/vbtkit/src/lego/: ZChassisVBT.m3 m3makefile
        cm3/m3-ui/vbtkit/src/lego/POSIX/: m3makefile
        cm3/m3-ui/vbtkit/src/lego/WIN32/: m3makefile
Removed files:
        cm3/m3-ui/vbtkit/src/lego/POSIX/: ZChassisVBT.m3
        cm3/m3-ui/vbtkit/src/lego/WIN32/: ZChassisVBT.m3

Log message:
        unfork ZChassisVBT.m3

        instead of copying 140 lines and changing a few, when
        both variations are portable, you can test
        Compiler.ThisOS = Compiler.OS.POSIX or Compiler.OS.WIN32
        and just have both variations.

        Alternately, make a /smaller/ interface and /smaller/ implementation
        that just contains the changed functions/lines

        The larger ScrollerVBTClass.m3 file received more churn so
        merging might not be viable/worthwhile.

        Besides, the Posix gui is terrible here, G for grow, C for close,
        we should probably just use the Win32 gui everywhere.


CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s).  This email may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.


From jay.krell at cornell.edu  Tue May 11 00:17:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 10 May 2010 22:17:05 +0000
Subject: [M3devel] program vs. Program
In-Reply-To: <20100510174015.0s21r39i68ck80sc@mail.elegosoft.com>
References: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>,
	<358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>,
	<20100510174015.0s21r39i68ck80sc@mail.elegosoft.com>
Message-ID: <COL101-W16DE2F184010AA8A1AFF44E6F90@phx.gbl>


>>> - never ship "program" -- not runable within the package store
>
> Would be a non-compatible change.
 
 
It's already non-compatible imho, except if LD_LIBRARY_PATH is used.
 

>>> - drop in wrapper .sh files that set/append LD_LIBRARY_PATH?
>
> Strange.
 
 
I believe this is a practise in the wider world, though not
very common or considered very good.
 
Actually some things I read say LD_LIBRARY_PATH is meant for
running stuff before install. Just don't abuse it and
use it after install. (it is the old link below though,
I should read more)
 

> Why not use the correct paths via $ORIGIN? For program they are
> of course different than for Program. Too difficult?
 
 
Ah, like ../../lib? To go our of pkg/target and over to lib?
Yeah, that is possible.
I had that in, but such "far up" relative paths worry me.
If the program is moved around to a shallower structure
it could accidentally reach into unrelated stuff.
 
 
It is mitigated by using:
  $ORIGIN:$ORIGIN/../lib:$ORIGIN/../../lib
 
 
so at least you find closer stuff first.
Maybe we can put just the last element in for program.
 
 
> http://xahlee.org/UnixResource_dir/_/ldpath.html
 
 
This is an old link, mostly predates $ORIGIN,
but does bring up the possibility of
linking or editing paths at install time.
 
 
Controversial suggestion: use autoconf/libtool.
It probably handles this stuff already.
 
 
 - Jay
  		 	   		  

From wagner at elegosoft.com  Wed May 12 08:51:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 12 May 2010 08:51:24 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>,
	<20100511090214.5bsr2f24o4oscg88@mail.elegosof, t, .com>, <F6
	43890B-0 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>
Message-ID: <20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>

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

>> It's nothing like just shifting the jobs from Jay's machine to opencsw.
>> I've already made half a dozen changes for a simple compile job.
>
>
> Hm. Maybe I should try installing Solaris 2.9 on my machine? Or a   
> separate machine first?
> I would like to offload to Dago if possible.

I understand that.

I can now check out with CVS from the command line, both via the
pserver proxy and a forwarded port via ssh, but still no luck with
Hudson itself. The failure message stays the same
(see http://hudson.modula3.com:8080/view/SOLsun/job/dummy/7/console).

Ideas what's going on are welcome.

But it's not just CVS. The regression test scripts check for
explicit ssh reachability of birch.elegosoft.com; we need scp
or rsync to upload archives, and wget or curl to download.
I'm sure the list will get even longer if we inspect the existing
jobs.

> I had tried to install Solaris 2.8 and/or 2.9 at some point but hit   
> some difficulty.
> 2.10 I've now installed multiple times, it is fairly easy.
>
> So..remember..I don't have any fixed IP addresses at all.
> I use free dynamic DNS and port forwarding.
>   Stuff I didn't know about but Olaf pointed me toward and I'm   
> pleased with it. :)
> Is that viable here?
>   You wouldn't need dynamic DNS, just port forwarding. As I understand.
> Like, port 222 on login goes to 22 on current9s, stuff like that.

I doubt that opencsw will change their setup for m3.

I'm sure we can work around every little or big problem that comes
up, but I simply haven't got the time for it.

I'd be happy if anybody else tries to port all the SOLsun jobs
from http://hudson.modula3.com:8080/view/SOLsun/
(copy to another name and then adapt) to run on
http://hudson.modula3.com:8080/computer/opencsw_current9s/.

My simple test job currently is in
http://hudson.modula3.com:8080/view/SOLsun/job/dummy/

If nobody else volunteers, I'll try to work on it now and then, but
cannot promise any deadline.

Thanks for all your support,

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 May 12 09:43:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 12 May 2010 07:43:35 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4oscg88@mail.el egosof,
	t, .com>, <F6,43890B-0
	0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>
Message-ID: <COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>


> test scripts check for explicit ssh reachability of birch.elegosoft.com
 
 
I put that in.
I found the stuff too hard to use and would try to make it easier as I figured it out.
 
 
 
Well.. for now let's just leave Hudson on my machine asis.
  Maybe Tony can provide a machine?
 
 
 
So..a general dilemna is how to give Dago something for him giving us something.
And how much is enough on either side?
Don't want to take and not give back, or whatnot.
 
 
 
I386_SOLARIS, AMD64_SOLARIS are now in good shape.
See http://www.modula3.com/cm3/uploaded-archives/index.html.
 
 
 
System builds itself.
  The whole thing on x86/2.10. Up to opengl on x86/2.9.
    I think I'll just do an existance check on 2.9 and stuff built there will just omit it.
 
  I haven't tested the X apps yet.
 
  I haven't tried Sparc32/64 yet on 2.8/2.9, but they could very well work ok.
     2.8 would have a problem with user threads, but I know how to fix it.
     (Dago is ok dropping 2.8 anyway, and user threads also don't really matter).
 
 
How much value is there to an occasional manual build, vs. better automation?
  With or without running the tests?
  Like, not hudson?
 
 
At some point I'll probably setup Solaris/x86.
  I already have, multiple times, just haven't configured it to my liking and kept it up and running.
  But I'd like to offload some power/heat/environmental-responsibility maybe.
  Maybe trade for other OSes. :)
  Also distribute the responsibility anyway. You don't want it all depending on my network connectivity, even if it was good. :)
 
 
I may have another option for Solaris. I'll check.
 
 
I can think of somewhat rude suggestions, like:
   Commit access shall be limited unless commiter provides Hudson resources. :)
   Of any sort or non-zero quantity -- don't make things too hard.
   Heck -- surely Linux/x86 is among the easiest for anyone to take. :)
   Then again, I'm not a manager, maybe I shouldn't try to think of ways to motivate people. :)
 
 
Also maybe login is usable at least for Solaris 2.10 sparc stuff?
Or is that an abuse?
 
 
 
Thanks,
 - Jay


----------------------------------------
> Date: Wed, 12 May 2010 08:51:24 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; trygvis at opencsw.org; dam at baltic-online.de
> Subject: Re: [M3devel] OpenCSW build farm access
>
> Quoting Jay K :
>
>>> It's nothing like just shifting the jobs from Jay's machine to opencsw.
>>> I've already made half a dozen changes for a simple compile job.
>>
>>
>> Hm. Maybe I should try installing Solaris 2.9 on my machine? Or a
>> separate machine first?
>> I would like to offload to Dago if possible.
>
> I understand that.
>
> I can now check out with CVS from the command line, both via the
> pserver proxy and a forwarded port via ssh, but still no luck with
> Hudson itself. The failure message stays the same
> (see http://hudson.modula3.com:8080/view/SOLsun/job/dummy/7/console).
>
> Ideas what's going on are welcome.
>
> But it's not just CVS. The regression test scripts check for
> explicit ssh reachability of birch.elegosoft.com; we need scp
> or rsync to upload archives, and wget or curl to download.
> I'm sure the list will get even longer if we inspect the existing
> jobs.
>
>> I had tried to install Solaris 2.8 and/or 2.9 at some point but hit
>> some difficulty.
>> 2.10 I've now installed multiple times, it is fairly easy.
>>
>> So..remember..I don't have any fixed IP addresses at all.
>> I use free dynamic DNS and port forwarding.
>> Stuff I didn't know about but Olaf pointed me toward and I'm
>> pleased with it. :)
>> Is that viable here?
>> You wouldn't need dynamic DNS, just port forwarding. As I understand.
>> Like, port 222 on login goes to 22 on current9s, stuff like that.
>
> I doubt that opencsw will change their setup for m3.
>
> I'm sure we can work around every little or big problem that comes
> up, but I simply haven't got the time for it.
>
> I'd be happy if anybody else tries to port all the SOLsun jobs
> from http://hudson.modula3.com:8080/view/SOLsun/
> (copy to another name and then adapt) to run on
> http://hudson.modula3.com:8080/computer/opencsw_current9s/.
>
> My simple test job currently is in
> http://hudson.modula3.com:8080/view/SOLsun/job/dummy/
>
> If nobody else volunteers, I'll try to work on it now and then, but
> cannot promise any deadline.
>
> Thanks for all your support,
>
> 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 May 12 11:39:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 12 May 2010 09:39:22 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof
	, t, .com>, <F6,43890B-0
	0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
Message-ID: <COL101-W266A3DC1739A617839710BE6FB0@phx.gbl>


Just to clarify: "leave the stuff on my machine for now" is more like
"I'm not pulling the plug, take your time with Dago"
and less like "give up on Dago".

I think the Hudson init script written in Groovy be the place
to fix $PATH, to find cvs.
Give me a bit..

?> another source for Solaris cycles

Like, someone who
?- has an easier network topology
?- no Solaris 2.9 desire/agenda, who we therefore won't disappoint
??? if we don't get 2.9 working

so we don't "steal" from Dago.
(Yes, I realize I'm being wishy-washy here..)

I agree though if you already have people using Hudson...

Give me a bit on the path/cvs thing.

And I have multiple options for x86 2.9 OpenGL.

?- Jay

----------------------------------------
> CC: wagner at elegosoft.com; m3devel at elegosoft.com; trygvis at opencsw.org
> From: dam at baltic-online.de
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] OpenCSW build farm access
> Date: Wed, 12 May 2010 11:05:37 +0200
>
> Hi,
>
> Am 12.05.2010 um 09:43 schrieb Jay K:
>> Well.. for now let's just leave Hudson on my machine asis.
>> Maybe Tony can provide a machine?
>
> I'm pretty sure we can work this out. Other projects are using
> the farm also with Hudson, so it should be quite possible in the
> current configuration.
>
>> So..a general dilemna is how to give Dago something for him giving
>> us something.
>> And how much is enough on either side?
>> Don't want to take and not give back, or whatnot.
>
> Just provide cvsup for Solaris 9 sparc/x86 and I am happy :-)
> Additionally,
> a goal of providing the buildfarm is to aid upstream projects in
> ensuring
> Solaris compatibility. As you obviously do that it is perfectly ok.
>
>> I386_SOLARIS, AMD64_SOLARIS are now in good shape.
>> See http://www.modula3.com/cm3/uploaded-archives/index.html.
>
> Cool.
>
>> System builds itself.
>> The whole thing on x86/2.10. Up to opengl on x86/2.9.
>> I think I'll just do an existance check on 2.9 and stuff built
>> there will just omit it.
>>
>> I haven't tested the X apps yet.
>>
>> I haven't tried Sparc32/64 yet on 2.8/2.9, but they could very well
>> work ok.
>> 2.8 would have a problem with user threads, but I know how to
>> fix it.
>> (Dago is ok dropping 2.8 anyway, and user threads also don't
>> really matter).
>
> Yes.
>
>> How much value is there to an occasional manual build, vs. better
>> automation?
>> With or without running the tests?
>> Like, not hudson?
>>
>> At some point I'll probably setup Solaris/x86.
>> I already have, multiple times, just haven't configured it to my
>> liking and kept it up and running.
>> But I'd like to offload some power/heat/environmental-
>> responsibility maybe.
>> Maybe trade for other OSes. :)
>> Also distribute the responsibility anyway. You don't want it all
>> depending on my network connectivity, even if it was good. :)
>>
>> I may have another option for Solaris. I'll check.
>
> I do feel offended ;-)
>
>> I can think of somewhat rude suggestions, like:
>> Commit access shall be limited unless commiter provides Hudson
>> resources. :)
>> Of any sort or non-zero quantity -- don't make things too hard.
>> Heck -- surely Linux/x86 is among the easiest for anyone to take. :)
>> Then again, I'm not a manager, maybe I shouldn't try to think of
>> ways to motivate people. :)
>>
>> Also maybe login is usable at least for Solaris 2.10 sparc stuff?
>> Or is that an abuse?
>
> It is not abuse, but there is no compiler there.
>
>
> Best regards
>
> -- Dago
>
 		 	   		  

From jay.krell at cornell.edu  Wed May 12 14:29:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 12 May 2010 12:29:28 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof ,, t, .com>,
	<F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
Message-ID: <COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>


Olaf, I have some leads:


1)

http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds#Distributedbuilds-Example%3AConfigurationonUnix

# /var/hudson/bin/launch-slave is a shell script that Hudson uses to execute jobs remotely. This shell script sets up PATH and a few other things before launching slave.jar. Below is a very simple example script.

#!/bin/bash

JAVA_HOME=/opt/SUN/jdk1.6.0_04
PATH=$PATH:$JAVA_HOME/bin
export PATH
java -jar /var/hudson/bin/slave.jar

On master or slave or ??

2)
You can modify $PATH across all nodes:
http://www.modula3.com:8080/configure
Global Properties: Environment variables
This is yucky but appears easy and would work.

3)
You can specify CVS executable there.
Maybe ~/cvs or $HOME/cvs ??????
Which we'd setup appropriately.


4)
Hudson initialization script.
http://wiki.hudson-ci.org/display/HUDSON/Post-initialization+script
$HUDSON_HOME/init.groovy
I'm not sure this runs on slave or master.
I'd want to remove :/opt/csw/bin:, /opt/csw/bin:
from start, :/opt/csw/bin from end, and then insert /opt/csw/bin
somewhere, like start. That's too much Groovy for me to write,
and get working within Hudson..there is System.getenv, but
I don't see how to set the variables.


5)
You can set "tool locations".
I can't find elaboration on what that means.
Maybe
tool=cvs
location=/opt/csw/bin/cvs
?

6)
There is some mention of "PATH+".
I tried that. Didn't work.

7)
http://hudson.361315.n4.nabble.com/Slave-environment-and-Java-path-issues-td383751.html#a383752

Thanks.? You correct that I didn't understand the difference when using a non-interactive shell.
In the end I solved the problem by putting together a simple launch-slave script which sets the environment I need:

#!/bin/bash

export JAVA_HOME=/usr/lib/java 
...


8)
http://hudson.361315.n4.nabble.com/slave-s-PATH-change-not-picked-up-td1558100.html#a1559051

You were right.? The ssh itself did not load the correct PATH (I
couldn't see it via putty).? It turns out ssh does not read
/etc/profile, but it does read user's .bashrc.? Go figure...


Maybe I'll fiddle with the Hudson keys or my old key and poke around more...


?- Jay 		 	   		  

From wagner at elegosoft.com  Wed May 12 16:09:37 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 12 May 2010 16:09:37 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof ,, t, .com>,
	<F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
Message-ID: <20100512160937.5kq1fothc44c4sck@mail.elegosoft.com>

Hi Jay,

thanks for your suggestions.

I'll try to get it working tomorrow. One of them should do :-)

Olaf

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

>
> Olaf, I have some leads:
>
>
> 1)
>
> http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds#Distributedbuilds-Example%3AConfigurationonUnix
>
> # /var/hudson/bin/launch-slave is a shell script that Hudson uses to  
>  execute jobs remotely. This shell script sets up PATH and a few   
> other things before launching slave.jar. Below is a very simple   
> example script.
>
> #!/bin/bash
>
> JAVA_HOME=/opt/SUN/jdk1.6.0_04
> PATH=$PATH:$JAVA_HOME/bin
> export PATH
> java -jar /var/hudson/bin/slave.jar
>
> On master or slave or ??
>
> 2)
> You can modify $PATH across all nodes:
> http://www.modula3.com:8080/configure
> Global Properties: Environment variables
> This is yucky but appears easy and would work.
>
> 3)
> You can specify CVS executable there.
> Maybe ~/cvs or $HOME/cvs ??????
> Which we'd setup appropriately.
>
>
> 4)
> Hudson initialization script.
> http://wiki.hudson-ci.org/display/HUDSON/Post-initialization+script
> $HUDSON_HOME/init.groovy
> I'm not sure this runs on slave or master.
> I'd want to remove :/opt/csw/bin:, /opt/csw/bin:
> from start, :/opt/csw/bin from end, and then insert /opt/csw/bin
> somewhere, like start. That's too much Groovy for me to write,
> and get working within Hudson..there is System.getenv, but
> I don't see how to set the variables.
>
>
> 5)
> You can set "tool locations".
> I can't find elaboration on what that means.
> Maybe
> tool=cvs
> location=/opt/csw/bin/cvs
> ?
>
> 6)
> There is some mention of "PATH+".
> I tried that. Didn't work.
>
> 7)
> http://hudson.361315.n4.nabble.com/Slave-environment-and-Java-path-issues-td383751.html#a383752
>
> Thanks.? You correct that I didn't understand the difference when   
> using a non-interactive shell.
> In the end I solved the problem by putting together a simple   
> launch-slave script which sets the environment I need:
>
> #!/bin/bash
>
> export JAVA_HOME=/usr/lib/java
> ...
>
>
> 8)
> http://hudson.361315.n4.nabble.com/slave-s-PATH-change-not-picked-up-td1558100.html#a1559051
>
> You were right.? The ssh itself did not load the correct PATH (I
> couldn't see it via putty).? It turns out ssh does not read
> /etc/profile, but it does read user's .bashrc.? Go figure...
>
>
> Maybe I'll fiddle with the Hudson keys or my old key and poke around more...
>
>
> ?- Jay



-- 
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  Thu May 13 16:05:21 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 13 May 2010 16:05:21 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof ,, t, .com>,
	<F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
Message-ID: <20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>

I finally managed to get CVS working.

I postponed current9s and set up some jobs on current10s, as that
should be equivalent to your machine, Jay.

However, compilation of the cm3cg1 backed fails:

http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console

Can you have a look?

TIA,

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 May 14 00:12:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 13 May 2010 22:12:31 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, !, cg88@mail .,elegos of ,, t,
	.com>, , <F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
Message-ID: <COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>


This will be easy. Several options.
 
 - Look at 4.5.0 and how they fixed it to compile with Sun cc.
   Since they probably did, compiling gcc with Sun cc is something people are interested/willing to do.
 
 - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
 
 - Maybe just change your $PATH, but I'd prefer previous.
 
Later.
 
 - Jay


----------------------------------------
> Date: Thu, 13 May 2010 16:05:21 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
> Subject: RE: [M3devel] OpenCSW build farm access
>
> I finally managed to get CVS working.
>
> I postponed current9s and set up some jobs on current10s, as that
> should be equivalent to your machine, Jay.
>
> However, compilation of the cm3cg1 backed fails:
>
> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>
> Can you have a look?
>
> TIA,
>
> 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  Fri May 14 00:49:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 14 May 2010 00:49:24 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, !, cg88@mail .,elegos of ,, t,
	.com>, , <F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
Message-ID: <20100514004924.je7gtb922o40wck8@mail.elegosoft.com>

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

> This will be easy. Several options.
>
>  - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>    Since they probably did, compiling gcc with Sun cc is something   
> people are interested/willing to do.
>
>  - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>
>  - Maybe just change your $PATH, but I'd prefer previous.
>
> Later.

In the meantime, I put gcc in the path, which is a bit like cheating...
Now the first job has succeeded :-)
cm3-build still has other problems. I hope to have one set of working
jobs on current10s by tomorrow evening.

Olaf

>  - Jay
>
>
> ----------------------------------------
>> Date: Thu, 13 May 2010 16:05:21 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>> Subject: RE: [M3devel] OpenCSW build farm access
>>
>> I finally managed to get CVS working.
>>
>> I postponed current9s and set up some jobs on current10s, as that
>> should be equivalent to your machine, Jay.
>>
>> However, compilation of the cm3cg1 backed fails:
>>
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>
>> Can you have a look?
>>
>> TIA,
>>
>> 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
>>



-- 
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  Fri May 14 07:52:45 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 14 May 2010 07:52:45 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, !, cg88@mail .,elegos of ,, t,
	.com>, , <F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
Message-ID: <20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>

Hi again,

with some tweaking, some `standard' Hudson jobs have now complete
for cm3 on current10s.

I've now got an overview: seven packages do not compile:

http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/

m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
IMO they should compile with cc, too, though.

I'm off again now and may have a look again later,

Olaf

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

> This will be easy. Several options.
>
>  - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>    Since they probably did, compiling gcc with Sun cc is something   
> people are interested/willing to do.
>
>  - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>
>  - Maybe just change your $PATH, but I'd prefer previous.
>
> Later.
>
>  - Jay
>
>
> ----------------------------------------
>> Date: Thu, 13 May 2010 16:05:21 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>> Subject: RE: [M3devel] OpenCSW build farm access
>>
>> I finally managed to get CVS working.
>>
>> I postponed current9s and set up some jobs on current10s, as that
>> should be equivalent to your machine, Jay.
>>
>> However, compilation of the cm3cg1 backed fails:
>>
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>
>> Can you have a look?
>>
>> TIA,
>>
>> 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 May 14 08:27:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 06:27:49 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, , !, cg88@mai l,.,eleg os of ,,
	t, , .com>, , <F6, 43890B-0,
	0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>,
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>,
	<20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>
Message-ID: <COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>


Having to use gcc to compile gcc and gdb is not new, and is probably the way it has always been (from our point of view).
There is even configuration around, how to run gcc and what flags to give it, separate from SYSTEM_CC.

However, I do believe current gcc can be built with Sun cc. But I vaguely recall the patches aren't small.
I'll see.

It looks like opengl failed..and if this wasn't release branch, I'd say I broke it..
I'll look more either way.

I don't know what's up with this "libstable" stuff but I'll look more.
Could maybe be just lack of postgres or something?

More later (or maybe just commits).

?- Jay

----------------------------------------
> Date: Fri, 14 May 2010 07:52:45 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
> Subject: RE: [M3devel] OpenCSW build farm access
>
> Hi again,
>
> with some tweaking, some `standard' Hudson jobs have now complete
> for cm3 on current10s.
>
> I've now got an overview: seven packages do not compile:
>
> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/
>
> m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
> IMO they should compile with cc, too, though.
>
> I'm off again now and may have a look again later,
>
> Olaf
>
> Quoting Jay K :
>
>> This will be easy. Several options.
>>
>> - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>> Since they probably did, compiling gcc with Sun cc is something
>> people are interested/willing to do.
>>
>> - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>>
>> - Maybe just change your $PATH, but I'd prefer previous.
>>
>> Later.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> Date: Thu, 13 May 2010 16:05:21 +0200
>>> From: wagner at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>
>>> I finally managed to get CVS working.
>>>
>>> I postponed current9s and set up some jobs on current10s, as that
>>> should be equivalent to your machine, Jay.
>>>
>>> However, compilation of the cm3cg1 backed fails:
>>>
>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>>
>>> Can you have a look?
>>>
>>> TIA,
>>>
>>> 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 May 14 08:37:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 06:37:07 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
Message-ID: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>


I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).

SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
? The data in the assembly looks like. Maybe a runtime memory corruption.


PPC32_OPENBSD complains something like in TextCat that a type is missing.
?I think it used to mostly work since I deleted some install I had there.


SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
(gdb) disassem
Dump of assembler code for function RTLinker__InitRuntime:
0x00000000004bd01c <RTLinker__InitRuntime+0>:?? save? %sp, -224, %sp
0x00000000004bd020 <RTLinker__InitRuntime+4>:?? sethi? %hi(0xd18800), %l7
0x00000000004bd024 <RTLinker__InitRuntime+8>:?? add? %l7, 0x1fc, %l7??? ! 0xd189fc
0x00000000004bd028 <RTLinker__InitRuntime+12>:? call? 0x4bd010 <_m3_fault+60> 
0x00000000004bd02c <RTLinker__InitRuntime+16>:? nop 
0x00000000004bd030 <RTLinker__InitRuntime+20>:? stx? %i0, [ %fp + 0x87f ]
0x00000000004bd034 <RTLinker__InitRuntime+24>:? stx? %i1, [ %fp + 0x887 ]
0x00000000004bd038 <RTLinker__InitRuntime+28>:? stx? %i2, [ %fp + 0x88f ]
0x00000000004bd03c <RTLinker__InitRuntime+32>:? stx? %i3, [ %fp + 0x897 ]
0x00000000004bd040 <RTLinker__InitRuntime+36>:? sethi? %hi(0x942c00), %g1
0x00000000004bd044 <RTLinker__InitRuntime+40>:? or? %g1, 0x290, %g1???? ! 0x942e90 <MM_RTLinker>
0x00000000004bd048 <RTLinker__InitRuntime+44>:? ldx? [ %l7 + %g1 ], %g1? << here


This seems like it'll be tough going. :(


I think I'll try with PIC? turned off.

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Fri May 14 09:25:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 07:25:30 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	,,<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>,
	,,<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	,,<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>,
	,,<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>,
	,,<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>,
	,,<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>,
	,,<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>,
	,,<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>,
	,,<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>,
	,,<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>,
	,,<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>,
	,,<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>,
	,,<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>,
	,,<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>,
	,,<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>,
	,,<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>,
	,,<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>,
	, , <20100511090214.5bsr2f24o4os, , !, cg88@mai l, ., eleg os of , , , t,
	, .com>, 
	, <F6, 43890B-0,,0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>,
	,,<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>,
	,,<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>,
	,,<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>,
	, , <20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>, ,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>, ,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>, ,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>, ,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>, ,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>, ,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>, ,
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>, ,
	<20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>,
	<COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>
Message-ID: <COL101-W48E4F207218CBFA9DF43E3E6FD0@phx.gbl>


Olaf, it looks like the "build" part only builds "core".
Unless there is an error, then it builds more.
Isn't that wrong?

Anyway, I can see the "test" part tries to build everything anyway, and it fails creating the symlink libopengl.so.5.
Wierd.

I'll see if I can reproduce this.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com
> Date: Fri, 14 May 2010 06:27:49 +0000
> CC: m3devel at elegosoft.com; trygvis at opencsw.org; dam at baltic-online.de
> Subject: Re: [M3devel] OpenCSW build farm access
>
>
> Having to use gcc to compile gcc and gdb is not new, and is probably the way it has always been (from our point of view).
> There is even configuration around, how to run gcc and what flags to give it, separate from SYSTEM_CC.
>
> However, I do believe current gcc can be built with Sun cc. But I vaguely recall the patches aren't small.
> I'll see.
>
> It looks like opengl failed..and if this wasn't release branch, I'd say I broke it..
> I'll look more either way.
>
> I don't know what's up with this "libstable" stuff but I'll look more.
> Could maybe be just lack of postgres or something?
>
> More later (or maybe just commits).
>
>  - Jay
>
> ----------------------------------------
>> Date: Fri, 14 May 2010 07:52:45 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>> Subject: RE: [M3devel] OpenCSW build farm access
>>
>> Hi again,
>>
>> with some tweaking, some `standard' Hudson jobs have now complete
>> for cm3 on current10s.
>>
>> I've now got an overview: seven packages do not compile:
>>
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/
>>
>> m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
>> IMO they should compile with cc, too, though.
>>
>> I'm off again now and may have a look again later,
>>
>> Olaf
>>
>> Quoting Jay K :
>>
>>> This will be easy. Several options.
>>>
>>> - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>>> Since they probably did, compiling gcc with Sun cc is something
>>> people are interested/willing to do.
>>>
>>> - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>>>
>>> - Maybe just change your $PATH, but I'd prefer previous.
>>>
>>> Later.
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> Date: Thu, 13 May 2010 16:05:21 +0200
>>>> From: wagner at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>>
>>>> I finally managed to get CVS working.
>>>>
>>>> I postponed current9s and set up some jobs on current10s, as that
>>>> should be equivalent to your machine, Jay.
>>>>
>>>> However, compilation of the cm3cg1 backed fails:
>>>>
>>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>>>
>>>> Can you have a look?
>>>>
>>>> TIA,
>>>>
>>>> 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 May 14 11:08:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 09:08:58 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>
Message-ID: <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>


Hm. Something is wrong on many platforms, in head, at least with my boot archives.
? PPC_DARWIN, SOLsun, I386_LINUX
I'll figure it out. Hopefully soon.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Fri, 14 May 2010 06:37:07 +0000
> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>
> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>   The data in the assembly looks like. Maybe a runtime memory corruption.
>
>
> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>  I think it used to mostly work since I deleted some install I had there.
>
>
> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
> (gdb) disassem
> Dump of assembler code for function RTLinker__InitRuntime:
> 0x00000000004bd01c :   save  %sp, -224, %sp
> 0x00000000004bd020 :   sethi  %hi(0xd18800), %l7
> 0x00000000004bd024 :   add  %l7, 0x1fc, %l7    ! 0xd189fc
> 0x00000000004bd028 :  call  0x4bd010 <_m3_fault+60>
> 0x00000000004bd02c :  nop
> 0x00000000004bd030 :  stx  %i0, [ %fp + 0x87f ]
> 0x00000000004bd034 :  stx  %i1, [ %fp + 0x887 ]
> 0x00000000004bd038 :  stx  %i2, [ %fp + 0x88f ]
> 0x00000000004bd03c :  stx  %i3, [ %fp + 0x897 ]
> 0x00000000004bd040 :  sethi  %hi(0x942c00), %g1
> 0x00000000004bd044 :  or  %g1, 0x290, %g1     ! 0x942e90 
> 0x00000000004bd048 :  ldx  [ %l7 + %g1 ], %g1  << here
>
>
> This seems like it'll be tough going. :(
>
>
> I think I'll try with PIC  turned off.
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Fri May 14 12:27:36 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 10:27:36 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>
Message-ID: <COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>


ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
Then I'll have to narrow it down some -- there are two main sets of changes:
?- my changes to set operations ? 
?- my change to div/mod
?- Tony's to bit field operations? 

It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.

I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
to keep them if they don't work.
?(Well, hopefully the NT386 versions can stay. :) )

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Fri, 14 May 2010 09:08:58 +0000
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>   PPC_DARWIN, SOLsun, I386_LINUX
> I'll figure it out. Hopefully soon.
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Fri, 14 May 2010 06:37:07 +0000
>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>
>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>
>>
>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>> I think it used to mostly work since I deleted some install I had there.
>>
>>
>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>> (gdb) disassem
>> Dump of assembler code for function RTLinker__InitRuntime:
>> 0x00000000004bd01c : save %sp, -224, %sp
>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>> 0x00000000004bd02c : nop
>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>
>>
>> This seems like it'll be tough going. :(
>>
>>
>> I think I'll try with PIC turned off.
>>
>> - Jay
>>
>>
>
 		 	   		  

From hosking at cs.purdue.edu  Fri May 14 15:59:02 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 14 May 2010 09:59:02 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>
Message-ID: <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>

Argh.  I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.

Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels.  I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution.  This is fragile stuff... and it may just be a bug in gcc that we are exercising.

It may be that we just need to update the backend to a newer version of gcc.  It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been.  Problem is that newer gcc may not play nice with older targets.  I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.

On 14 May 2010, at 06:27, Jay K wrote:

> 
> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
> Then I'll have to narrow it down some -- there are two main sets of changes:
>  - my changes to set operations   
>  - my change to div/mod
>  - Tony's to bit field operations  
> 
> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
> 
> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
> to keep them if they don't work.
>  (Well, hopefully the NT386 versions can stay. :) )
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Fri, 14 May 2010 09:08:58 +0000
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>  PPC_DARWIN, SOLsun, I386_LINUX
>> I'll figure it out. Hopefully soon.
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> 
>>> 
>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>> 
>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>> 
>>> 
>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>> I think it used to mostly work since I deleted some install I had there.
>>> 
>>> 
>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>> (gdb) disassem
>>> Dump of assembler code for function RTLinker__InitRuntime:
>>> 0x00000000004bd01c : save %sp, -224, %sp
>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>> 0x00000000004bd02c : nop
>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>> 
>>> 
>>> This seems like it'll be tough going. :(
>>> 
>>> 
>>> I think I'll try with PIC turned off.
>>> 
>>> - Jay
>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Fri May 14 19:58:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 17:58:29 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>
Message-ID: <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>


I don't think anything I've been fiddling with has been dropped by gcc, yet.
?I might have depended on Irix o32 to get up to a working gcc, but no matter.
?I agree if they drop it, we have to.
?Though we could also keep multiple gcc versions if there was really something we wanted,
? but that's not likely.
?A C generating backend also solves this.


I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
But I won't guarantee that now and am very willing to undo them if there is a problem.
?(big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).


?I don't remember about div/mod.
?While it seems "obvious" that the change is correct, it could be that that part of
?gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?


I'm also not optimizing at all.


I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
easily, and I'm also not keen on the huge testing matrix.
(I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)


If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.


Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
?SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).


?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 09:59:02 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>
> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>
> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>
> On 14 May 2010, at 06:27, Jay K wrote:
>
>>
>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>> Then I'll have to narrow it down some -- there are two main sets of changes:
>> - my changes to set operations
>> - my change to div/mod
>> - Tony's to bit field operations
>>
>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>
>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>> to keep them if they don't work.
>> (Well, hopefully the NT386 versions can stay. :) )
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>> PPC_DARWIN, SOLsun, I386_LINUX
>>> I'll figure it out. Hopefully soon.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>
>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>
>>>>
>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>> I think it used to mostly work since I deleted some install I had there.
>>>>
>>>>
>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>> (gdb) disassem
>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>> 0x00000000004bd02c : nop
>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>
>>>>
>>>> This seems like it'll be tough going. :(
>>>>
>>>>
>>>> I think I'll try with PIC turned off.
>>>>
>>>> - Jay
>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Fri May 14 20:25:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 18:25:59 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>,
	, , <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
Message-ID: <COL101-W19A08D5003AAF4F70340CCE6FD0@phx.gbl>


I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.


I have some extra time today, so, plan:
? retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
? test undo just the bitfield insert/extract change, see if that is the problem 
? work through the others if not 
? Possibly verify mod/div test coverage (unless it is the problem, in which
? case if I put it back, no need for test coverage, probably nobody will ever
? touch it again, which is fine. :) )
?I'm pretty sure I tested the set stuff well because I was very nervous but
? if others are ruled out I'll undo or test it.
? (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
?set changes. Only through experimentation/testing could I know that
?the definition of bit indices matched up between hand.c and the btc/bts instructions,
?it appeared to be a very convenient coincidence.)


I am surprised that I386_* working and broken.
I would think wordsize and endian is all that matters here.


I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
But moving up to 4.4.x or 4.5.x is welcome too. :)


?- Jay
?

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 17:58:29 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>  I might have depended on Irix o32 to get up to a working gcc, but no matter.
>  I agree if they drop it, we have to.
>  Though we could also keep multiple gcc versions if there was really something we wanted,
>   but that's not likely.
>  A C generating backend also solves this.
>
>
> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
> But I won't guarantee that now and am very willing to undo them if there is a problem.
>  (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>
>
>  I don't remember about div/mod.
>  While it seems "obvious" that the change is correct, it could be that that part of
>  gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>
>
> I'm also not optimizing at all.
>
>
> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
> easily, and I'm also not keen on the huge testing matrix.
> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>
>
> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>
>
> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>  SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>
>
>  - Jay
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 09:59:02 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>
>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>
>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>
>> On 14 May 2010, at 06:27, Jay K wrote:
>>
>>>
>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>> - my changes to set operations
>>> - my change to div/mod
>>> - Tony's to bit field operations
>>>
>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>
>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>> to keep them if they don't work.
>>> (Well, hopefully the NT386 versions can stay. :) )
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>> I'll figure it out. Hopefully soon.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: m3devel at elegosoft.com
>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>
>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>
>>>>>
>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>
>>>>>
>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>> (gdb) disassem
>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>> 0x00000000004bd02c : nop
>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>
>>>>>
>>>>> This seems like it'll be tough going. :(
>>>>>
>>>>>
>>>>> I think I'll try with PIC turned off.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From wagner at elegosoft.com  Sat May 15 00:09:13 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 15 May 2010 00:09:13 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W48E4F207218CBFA9DF43E3E6FD0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	,,<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>,
	,,<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	,,<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>,
	,,<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>,
	,,<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>,
	,,<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>,
	,,<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>,
	,,<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>,
	,,<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>,
	,,<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>,
	,,<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>,
	,,<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>,
	,,<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>,
	,,<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>,
	,,<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>,
	,,<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>,
	,,<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>,
	, , <20100511090214.5bsr2f24o4os, , !, cg88@mai l, ., eleg os of , , , t,
	, .com>, 
	, <F6, 43890B-0,,0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>,
	,,<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>,
	,,<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>,
	,,<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>,
	, , <20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>, ,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>, ,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>, ,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>, ,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>, ,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>, ,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>, ,
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>, ,
	<20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>,
	<COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>
	<COL101-W48E4F207218CBFA9DF43E3E6FD0@phx.gbl>
Message-ID: <20100515000913.3zzs4eu40swsgg0k@mail.elegosoft.com>

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

> Olaf, it looks like the "build" part only builds "core".
> Unless there is an error, then it builds more.
> Isn't that wrong?

I think it's always build just core. Why should it build more in case
of an error?

All packages are built and tested in the test-all-pkgs jobs.

> Anyway, I can see the "test" part tries to build everything anyway,   
> and it fails creating the symlink libopengl.so.5.
> Wierd.
>
> I'll see if I can reproduce this.

Strange. But to answer a question from your previous mail,
this is still the release branch. I just tried to port the existing
jobs now running on your machine first.

We can easily switch them to the trunk head though.

Olaf

> ?- Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: wagner at elegosoft.com
>> Date: Fri, 14 May 2010 06:27:49 +0000
>> CC: m3devel at elegosoft.com; trygvis at opencsw.org; dam at baltic-online.de
>> Subject: Re: [M3devel] OpenCSW build farm access
>>
>>
>> Having to use gcc to compile gcc and gdb is not new, and is   
>> probably the way it has always been (from our point of view).
>> There is even configuration around, how to run gcc and what flags   
>> to give it, separate from SYSTEM_CC.
>>
>> However, I do believe current gcc can be built with Sun cc. But I   
>> vaguely recall the patches aren't small.
>> I'll see.
>>
>> It looks like opengl failed..and if this wasn't release branch, I'd  
>>  say I broke it..
>> I'll look more either way.
>>
>> I don't know what's up with this "libstable" stuff but I'll look more.
>> Could maybe be just lack of postgres or something?
>>
>> More later (or maybe just commits).
>>
>>  - Jay
>>
>> ----------------------------------------
>>> Date: Fri, 14 May 2010 07:52:45 +0200
>>> From: wagner at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>
>>> Hi again,
>>>
>>> with some tweaking, some `standard' Hudson jobs have now complete
>>> for cm3 on current10s.
>>>
>>> I've now got an overview: seven packages do not compile:
>>>
>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/
>>>
>>> m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
>>> IMO they should compile with cc, too, though.
>>>
>>> I'm off again now and may have a look again later,
>>>
>>> Olaf
>>>
>>> Quoting Jay K :
>>>
>>>> This will be easy. Several options.
>>>>
>>>> - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>>>> Since they probably did, compiling gcc with Sun cc is something
>>>> people are interested/willing to do.
>>>>
>>>> - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>>>>
>>>> - Maybe just change your $PATH, but I'd prefer previous.
>>>>
>>>> Later.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Thu, 13 May 2010 16:05:21 +0200
>>>>> From: wagner at elegosoft.com
>>>>> To: jay.krell at cornell.edu
>>>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>>>
>>>>> I finally managed to get CVS working.
>>>>>
>>>>> I postponed current9s and set up some jobs on current10s, as that
>>>>> should be equivalent to your machine, Jay.
>>>>>
>>>>> However, compilation of the cm3cg1 backed fails:
>>>>>
>>>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>>>>
>>>>> Can you have a look?
>>>>>
>>>>> TIA,
>>>>>
>>>>> 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
>>>
>>
>



-- 
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  Sat May 15 00:13:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 22:13:58 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
Message-ID: <COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>


So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....

? - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
> Date: Fri, 14 May 2010 18:25:59 +0000
>
>
> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>
>
> I have some extra time today, so, plan:
>   retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>   test undo just the bitfield insert/extract change, see if that is the problem
>   work through the others if not
>   Possibly verify mod/div test coverage (unless it is the problem, in which
>   case if I put it back, no need for test coverage, probably nobody will ever
>   touch it again, which is fine. :) )
>  I'm pretty sure I tested the set stuff well because I was very nervous but
>   if others are ruled out I'll undo or test it.
>   (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>  set changes. Only through experimentation/testing could I know that
>  the definition of bit indices matched up between hand.c and the btc/bts instructions,
>  it appeared to be a very convenient coincidence.)
>
>
> I am surprised that I386_* working and broken.
> I would think wordsize and endian is all that matters here.
>
>
> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
> But moving up to 4.4.x or 4.5.x is welcome too. :)
>
>
>  - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 17:58:29 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>> I agree if they drop it, we have to.
>> Though we could also keep multiple gcc versions if there was really something we wanted,
>> but that's not likely.
>> A C generating backend also solves this.
>>
>>
>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>
>>
>> I don't remember about div/mod.
>> While it seems "obvious" that the change is correct, it could be that that part of
>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>
>>
>> I'm also not optimizing at all.
>>
>>
>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>> easily, and I'm also not keen on the huge testing matrix.
>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>
>>
>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>
>>
>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>
>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>
>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>
>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>
>>>>
>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>> - my changes to set operations
>>>> - my change to div/mod
>>>> - Tony's to bit field operations
>>>>
>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>
>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>> to keep them if they don't work.
>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: m3devel at elegosoft.com
>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>> I'll figure it out. Hopefully soon.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: m3devel at elegosoft.com
>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>
>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>
>>>>>>
>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>
>>>>>>
>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>> (gdb) disassem
>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>> 0x00000000004bd02c : nop
>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>
>>>>>>
>>>>>> This seems like it'll be tough going. :(
>>>>>>
>>>>>>
>>>>>> I think I'll try with PIC turned off.
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 02:24:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 00:24:03 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>,
	, , <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>
Message-ID: <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>


Tony I think it is your change to extract_mn.
Try it with SOLsun for example.
I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):


diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
77,78c77,78
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 22, %g1
> ??? srl??? %g1, 31, %g1
118,119c118,119
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 22, %g1
> ??? srl??? %g1, 31, %g1
197,198c197,198
< ??? srl??? %g1, 21, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 21, %g1
> ??? srl??? %g1, 31, %g1
236,237c236,237
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 22, %g1
> ??? srl??? %g1, 31, %g1
273,274c273,274
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1


This is not optimized.
They seem equally optimal, but very different.
? Assuming shifts are fast. Could be srl+and is faster than sll+srl.
? srl+and is clearer.
?I don't remember which of these worked.


< ??? srl??? %g1, 22, %g1

< ??? and??? %g1, 1, %g1

---

> ??? sll??? %g1, 22, %g1

> ??? srl??? %g1, 31, %g1



I read the first as:
? extract bit 22, plus or minus 1
vs.
? extract bit 32-22=10, plus or minus 1.


It would probably be ok to move bits around, but insert would have to match.


?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 22:13:58 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>
>   - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> Date: Fri, 14 May 2010 18:25:59 +0000
>>
>>
>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>
>>
>> I have some extra time today, so, plan:
>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>> test undo just the bitfield insert/extract change, see if that is the problem
>> work through the others if not
>> Possibly verify mod/div test coverage (unless it is the problem, in which
>> case if I put it back, no need for test coverage, probably nobody will ever
>> touch it again, which is fine. :) )
>> I'm pretty sure I tested the set stuff well because I was very nervous but
>> if others are ruled out I'll undo or test it.
>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>> set changes. Only through experimentation/testing could I know that
>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>> it appeared to be a very convenient coincidence.)
>>
>>
>> I am surprised that I386_* working and broken.
>> I would think wordsize and endian is all that matters here.
>>
>>
>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>> I agree if they drop it, we have to.
>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>> but that's not likely.
>>> A C generating backend also solves this.
>>>
>>>
>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>
>>>
>>> I don't remember about div/mod.
>>> While it seems "obvious" that the change is correct, it could be that that part of
>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>
>>>
>>> I'm also not optimizing at all.
>>>
>>>
>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>> easily, and I'm also not keen on the huge testing matrix.
>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>
>>>
>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>
>>>
>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>
>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>
>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>
>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>
>>>>>
>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>> - my changes to set operations
>>>>> - my change to div/mod
>>>>> - Tony's to bit field operations
>>>>>
>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>
>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>> to keep them if they don't work.
>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: m3devel at elegosoft.com
>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>> I'll figure it out. Hopefully soon.
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>
>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>
>>>>>>>
>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>
>>>>>>>
>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>> (gdb) disassem
>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>> 0x00000000004bd02c : nop
>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>
>>>>>>>
>>>>>>> This seems like it'll be tough going. :(
>>>>>>>
>>>>>>>
>>>>>>> I think I'll try with PIC turned off.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 03:07:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 01:07:27 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,
	, , , , <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , 
	, <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,
	, , <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
Message-ID: <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>


> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1

Er.
first: a = (a>> 22) & 1;
second: a = (a << 22)>> 31;

are actually darn close, maybe the same.
Let's just be lame and test in C:

#include <stdio.h>
int main()
{
unsigned a = ~0;
unsigned b = (a>> 22) & 1;
unsigned c = (a << 22)>> 31;
printf("%x %x\n", b, c);
return 0;
}

both print 1. So I remain a bit uncertain.
I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
I might dig more before commiting the undo.
Maybe bit fields of multiple bits are the only ones broken.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:24:03 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> Tony I think it is your change to extract_mn.
> Try it with SOLsun for example.
> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>
>
> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
> 77,78c77,78
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 118,119c118,119
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 197,198c197,198
> <     srl    %g1, 21, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 21, %g1
>>     srl    %g1, 31, %g1
> 236,237c236,237
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 273,274c273,274
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
>
>
> This is not optimized.
> They seem equally optimal, but very different.
>   Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>   srl+and is clearer.
>  I don't remember which of these worked.
>
>
> <     srl    %g1, 22, %g1
>
> <     and    %g1, 1, %g1
>
> ---
>
>>     sll    %g1, 22, %g1
>
>>     srl    %g1, 31, %g1
>
>
>
> I read the first as:
>   extract bit 22, plus or minus 1
> vs.
>   extract bit 32-22=10, plus or minus 1.
>
>
> It would probably be ok to move bits around, but insert would have to match.
>
>
>  - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 22:13:58 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>
>>>
>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>
>>>
>>> I have some extra time today, so, plan:
>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>> test undo just the bitfield insert/extract change, see if that is the problem
>>> work through the others if not
>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>> case if I put it back, no need for test coverage, probably nobody will ever
>>> touch it again, which is fine. :) )
>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>> if others are ruled out I'll undo or test it.
>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>> set changes. Only through experimentation/testing could I know that
>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>> it appeared to be a very convenient coincidence.)
>>>
>>>
>>> I am surprised that I386_* working and broken.
>>> I would think wordsize and endian is all that matters here.
>>>
>>>
>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>> I agree if they drop it, we have to.
>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>> but that's not likely.
>>>> A C generating backend also solves this.
>>>>
>>>>
>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>
>>>>
>>>> I don't remember about div/mod.
>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>
>>>>
>>>> I'm also not optimizing at all.
>>>>
>>>>
>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>> easily, and I'm also not keen on the huge testing matrix.
>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>
>>>>
>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>
>>>>
>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>
>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>
>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>
>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>
>>>>>>
>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>> - my changes to set operations
>>>>>> - my change to div/mod
>>>>>> - Tony's to bit field operations
>>>>>>
>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>
>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>> to keep them if they don't work.
>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>
>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>
>>>>>>>>
>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>
>>>>>>>>
>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>> (gdb) disassem
>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>
>>>>>>>>
>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>
>>>>>>>>
>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 03:29:01 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 01:29:01 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,,, , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , ,,,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,,, ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,
	, , <COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
Message-ID: <COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>


Well I'm feeling dumb. That test case surely would print 1 for almost anything.
A more accurate one, which shows a problem, is:

#include <stdio.h>

unsigned F1(unsigned a) { return ((a>> 22) & 1); }
unsigned F2(unsigned a) { return ((a << 22)>> 31); }

int main()
{
??? unsigned a = 1 << 22;
??? printf("%x %x\n", F1(a), F2(a));
??? return 0;
}

But I'm still having trouble convincing myself.
I guess the second might give you the 10th bit.
Er, the 9th.

#include <stdio.h>

unsigned F1(unsigned a) { return ((a>> 22) & 1); }
unsigned F2(unsigned a) { return ((a << 22)>> 31); }

int main()
{
??? unsigned a = 1 << 22;
??? printf("%x %x\n", F1(a), F2(a));

??? a = 1 << 9;
??? printf("%x %x\n", F1(a), F2(a));
??? return 0;
}

1 0
0 1

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 01:07:27 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>
> Er.
> first: a = (a>> 22) & 1;
> second: a = (a << 22)>> 31;
>
> are actually darn close, maybe the same.
> Let's just be lame and test in C:
>
> #include 
> int main()
> {
> unsigned a = ~0;
> unsigned b = (a>> 22) & 1;
> unsigned c = (a << 22)>> 31;
> printf("%x %x\n", b, c);
> return 0;
> }
>
> both print 1. So I remain a bit uncertain.
> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
> I might dig more before commiting the undo.
> Maybe bit fields of multiple bits are the only ones broken.
>
>  - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 00:24:03 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> Tony I think it is your change to extract_mn.
>> Try it with SOLsun for example.
>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>
>>
>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>> 77,78c77,78
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>> 118,119c118,119
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>> 197,198c197,198
>> < srl %g1, 21, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 21, %g1
>>> srl %g1, 31, %g1
>> 236,237c236,237
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>> 273,274c273,274
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>>
>>
>> This is not optimized.
>> They seem equally optimal, but very different.
>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>> srl+and is clearer.
>> I don't remember which of these worked.
>>
>>
>> < srl %g1, 22, %g1
>>
>> < and %g1, 1, %g1
>>
>> ---
>>
>>> sll %g1, 22, %g1
>>
>>> srl %g1, 31, %g1
>>
>>
>>
>> I read the first as:
>> extract bit 22, plus or minus 1
>> vs.
>> extract bit 32-22=10, plus or minus 1.
>>
>>
>> It would probably be ok to move bits around, but insert would have to match.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>
>>>>
>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>
>>>>
>>>> I have some extra time today, so, plan:
>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>> work through the others if not
>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>> touch it again, which is fine. :) )
>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>> if others are ruled out I'll undo or test it.
>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>> set changes. Only through experimentation/testing could I know that
>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>> it appeared to be a very convenient coincidence.)
>>>>
>>>>
>>>> I am surprised that I386_* working and broken.
>>>> I would think wordsize and endian is all that matters here.
>>>>
>>>>
>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>> I agree if they drop it, we have to.
>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>> but that's not likely.
>>>>> A C generating backend also solves this.
>>>>>
>>>>>
>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>
>>>>>
>>>>> I don't remember about div/mod.
>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>
>>>>>
>>>>> I'm also not optimizing at all.
>>>>>
>>>>>
>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>
>>>>>
>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>
>>>>>
>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>
>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>
>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>
>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>
>>>>>>>
>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>> - my changes to set operations
>>>>>>> - my change to div/mod
>>>>>>> - Tony's to bit field operations
>>>>>>>
>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>
>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>> to keep them if they don't work.
>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>
>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>> (gdb) disassem
>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 05:10:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 03:10:54 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,,, , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, ,
	,,,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, ,
	,,,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,,,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,,, ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>,
	, , <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>
Message-ID: <COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>


http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html

BIT_FIELD_REF considered harmful

We should try to use COMPONENT_REF instead.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 01:29:01 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
> A more accurate one, which shows a problem, is:
>
> #include 
>
> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>
> int main()
> {
>     unsigned a = 1 << 22;
>     printf("%x %x\n", F1(a), F2(a));
>     return 0;
> }
>
> But I'm still having trouble convincing myself.
> I guess the second might give you the 10th bit.
> Er, the 9th.
>
> #include 
>
> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>
> int main()
> {
>     unsigned a = 1 << 22;
>     printf("%x %x\n", F1(a), F2(a));
>
>     a = 1 << 9;
>     printf("%x %x\n", F1(a), F2(a));
>     return 0;
> }
>
> 1 0
> 0 1
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 01:07:27 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>
>> Er.
>> first: a = (a>> 22) & 1;
>> second: a = (a << 22)>> 31;
>>
>> are actually darn close, maybe the same.
>> Let's just be lame and test in C:
>>
>> #include
>> int main()
>> {
>> unsigned a = ~0;
>> unsigned b = (a>> 22) & 1;
>> unsigned c = (a << 22)>> 31;
>> printf("%x %x\n", b, c);
>> return 0;
>> }
>>
>> both print 1. So I remain a bit uncertain.
>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>> I might dig more before commiting the undo.
>> Maybe bit fields of multiple bits are the only ones broken.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Tony I think it is your change to extract_mn.
>>> Try it with SOLsun for example.
>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>
>>>
>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>> 77,78c77,78
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>> 118,119c118,119
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>> 197,198c197,198
>>> < srl %g1, 21, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 21, %g1
>>>> srl %g1, 31, %g1
>>> 236,237c236,237
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>> 273,274c273,274
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>>
>>>
>>> This is not optimized.
>>> They seem equally optimal, but very different.
>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>> srl+and is clearer.
>>> I don't remember which of these worked.
>>>
>>>
>>> < srl %g1, 22, %g1
>>>
>>> < and %g1, 1, %g1
>>>
>>> ---
>>>
>>>> sll %g1, 22, %g1
>>>
>>>> srl %g1, 31, %g1
>>>
>>>
>>>
>>> I read the first as:
>>> extract bit 22, plus or minus 1
>>> vs.
>>> extract bit 32-22=10, plus or minus 1.
>>>
>>>
>>> It would probably be ok to move bits around, but insert would have to match.
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>
>>>>>
>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>
>>>>>
>>>>> I have some extra time today, so, plan:
>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>> work through the others if not
>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>> touch it again, which is fine. :) )
>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>> if others are ruled out I'll undo or test it.
>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>> set changes. Only through experimentation/testing could I know that
>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>> it appeared to be a very convenient coincidence.)
>>>>>
>>>>>
>>>>> I am surprised that I386_* working and broken.
>>>>> I would think wordsize and endian is all that matters here.
>>>>>
>>>>>
>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>> I agree if they drop it, we have to.
>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>> but that's not likely.
>>>>>> A C generating backend also solves this.
>>>>>>
>>>>>>
>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>
>>>>>>
>>>>>> I don't remember about div/mod.
>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>
>>>>>>
>>>>>> I'm also not optimizing at all.
>>>>>>
>>>>>>
>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>
>>>>>>
>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>
>>>>>>
>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: hosking at cs.purdue.edu
>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>
>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>
>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>
>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>> - my changes to set operations
>>>>>>>> - my change to div/mod
>>>>>>>> - Tony's to bit field operations
>>>>>>>>
>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>
>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>> to keep them if they don't work.
>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>
>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>> (gdb) disassem
>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From hosking at cs.purdue.edu  Sat May 15 06:13:20 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 00:13:20 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
Message-ID: <00A2CBB5-0BD0-43B0-8C2B-5D7296048DAF@cs.purdue.edu>

Yeah.   Looks broken.  Please de-optimize extract_mn to what it was before.

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 14 May 2010, at 20:24, Jay K wrote:

> 
> Tony I think it is your change to extract_mn.
> Try it with SOLsun for example.
> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
> 
> 
> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
> 77,78c77,78
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 118,119c118,119
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 197,198c197,198
> <     srl    %g1, 21, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 21, %g1
>>     srl    %g1, 31, %g1
> 236,237c236,237
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 273,274c273,274
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> 
> 
> This is not optimized.
> They seem equally optimal, but very different.
>   Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>   srl+and is clearer.
>  I don't remember which of these worked.
> 
> 
> <     srl    %g1, 22, %g1
> 
> <     and    %g1, 1, %g1
> 
> ---
> 
>>     sll    %g1, 22, %g1
> 
>>     srl    %g1, 31, %g1
> 
> 
> 
> I read the first as:
>   extract bit 22, plus or minus 1
> vs.
>   extract bit 32-22=10, plus or minus 1.
> 
> 
> It would probably be ok to move bits around, but insert would have to match.
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 22:13:58 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>> 
>>  - Jay
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>> 
>>> 
>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>> 
>>> 
>>> I have some extra time today, so, plan:
>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>> test undo just the bitfield insert/extract change, see if that is the problem
>>> work through the others if not
>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>> case if I put it back, no need for test coverage, probably nobody will ever
>>> touch it again, which is fine. :) )
>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>> if others are ruled out I'll undo or test it.
>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>> set changes. Only through experimentation/testing could I know that
>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>> it appeared to be a very convenient coincidence.)
>>> 
>>> 
>>> I am surprised that I386_* working and broken.
>>> I would think wordsize and endian is all that matters here.
>>> 
>>> 
>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> 
>>>> 
>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>> I agree if they drop it, we have to.
>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>> but that's not likely.
>>>> A C generating backend also solves this.
>>>> 
>>>> 
>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>> 
>>>> 
>>>> I don't remember about div/mod.
>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>> 
>>>> 
>>>> I'm also not optimizing at all.
>>>> 
>>>> 
>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>> easily, and I'm also not keen on the huge testing matrix.
>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>> 
>>>> 
>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>> 
>>>> 
>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> 
>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>> 
>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>> 
>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>> 
>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>> 
>>>>>> 
>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>> - my changes to set operations
>>>>>> - my change to div/mod
>>>>>> - Tony's to bit field operations
>>>>>> 
>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>> 
>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>> to keep them if they don't work.
>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> 
>>>>>>> 
>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>> 
>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>> (gdb) disassem
>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>> 
>>>>>>>> 
>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>> 
>>>>>>>> - Jay
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  

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

From hosking at cs.purdue.edu  Sat May 15 06:14:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 00:14:08 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
Message-ID: <131F4BA5-0960-429D-B711-304FEE55A4F1@cs.purdue.edu>

It would be great if we could understand what is going on here, because as I recall the code looked to be correct, at least on x86.

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 14 May 2010, at 21:07, Jay K wrote:

> 
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
> 
> Er.
> first: a = (a>> 22) & 1;
> second: a = (a << 22)>> 31;
> 
> are actually darn close, maybe the same.
> Let's just be lame and test in C:
> 
> #include <stdio.h>
> int main()
> {
> unsigned a = ~0;
> unsigned b = (a>> 22) & 1;
> unsigned c = (a << 22)>> 31;
> printf("%x %x\n", b, c);
> return 0;
> }
> 
> both print 1. So I remain a bit uncertain.
> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
> I might dig more before commiting the undo.
> Maybe bit fields of multiple bits are the only ones broken.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 00:24:03 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> Tony I think it is your change to extract_mn.
>> Try it with SOLsun for example.
>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>> 
>> 
>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>> 77,78c77,78
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
>> 118,119c118,119
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
>> 197,198c197,198
>> <     srl    %g1, 21, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 21, %g1
>>>    srl    %g1, 31, %g1
>> 236,237c236,237
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
>> 273,274c273,274
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> 
>> 
>> This is not optimized.
>> They seem equally optimal, but very different.
>>  Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>  srl+and is clearer.
>> I don't remember which of these worked.
>> 
>> 
>> <     srl    %g1, 22, %g1
>> 
>> <     and    %g1, 1, %g1
>> 
>> ---
>> 
>>>    sll    %g1, 22, %g1
>> 
>>>    srl    %g1, 31, %g1
>> 
>> 
>> 
>> I read the first as:
>>  extract bit 22, plus or minus 1
>> vs.
>>  extract bit 32-22=10, plus or minus 1.
>> 
>> 
>> It would probably be ok to move bits around, but insert would have to match.
>> 
>> 
>> - Jay
>> 
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> 
>>> 
>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>> 
>>>> 
>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>> 
>>>> 
>>>> I have some extra time today, so, plan:
>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>> work through the others if not
>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>> touch it again, which is fine. :) )
>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>> if others are ruled out I'll undo or test it.
>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>> set changes. Only through experimentation/testing could I know that
>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>> it appeared to be a very convenient coincidence.)
>>>> 
>>>> 
>>>> I am surprised that I386_* working and broken.
>>>> I would think wordsize and endian is all that matters here.
>>>> 
>>>> 
>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> 
>>>>> 
>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>> I agree if they drop it, we have to.
>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>> but that's not likely.
>>>>> A C generating backend also solves this.
>>>>> 
>>>>> 
>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>> 
>>>>> 
>>>>> I don't remember about div/mod.
>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>> 
>>>>> 
>>>>> I'm also not optimizing at all.
>>>>> 
>>>>> 
>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>> 
>>>>> 
>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>> 
>>>>> 
>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>> 
>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>> 
>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>> 
>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>> 
>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>> 
>>>>>>> 
>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>> - my changes to set operations
>>>>>>> - my change to div/mod
>>>>>>> - Tony's to bit field operations
>>>>>>> 
>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>> 
>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>> to keep them if they don't work.
>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>> 
>>>>>>>> - Jay
>>>>>>>> 
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>> 
>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>> (gdb) disassem
>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>> 
>>>>>>>>> - Jay
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  

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

From hosking at cs.purdue.edu  Sat May 15 06:14:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 00:14:54 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>
Message-ID: <558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>

COMPONENT_REF is difficult because of the lack of type info I think.  Please revert to what it used to be.


On 14 May 2010, at 23:10, Jay K wrote:

> 
> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
> 
> BIT_FIELD_REF considered harmful
> 
> We should try to use COMPONENT_REF instead.
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 01:29:01 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>> A more accurate one, which shows a problem, is:
>> 
>> #include 
>> 
>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>> 
>> int main()
>> {
>>    unsigned a = 1 << 22;
>>    printf("%x %x\n", F1(a), F2(a));
>>    return 0;
>> }
>> 
>> But I'm still having trouble convincing myself.
>> I guess the second might give you the 10th bit.
>> Er, the 9th.
>> 
>> #include 
>> 
>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>> 
>> int main()
>> {
>>    unsigned a = 1 << 22;
>>    printf("%x %x\n", F1(a), F2(a));
>> 
>>    a = 1 << 9;
>>    printf("%x %x\n", F1(a), F2(a));
>>    return 0;
>> }
>> 
>> 1 0
>> 0 1
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> 
>>> 
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>> 
>>> Er.
>>> first: a = (a>> 22) & 1;
>>> second: a = (a << 22)>> 31;
>>> 
>>> are actually darn close, maybe the same.
>>> Let's just be lame and test in C:
>>> 
>>> #include
>>> int main()
>>> {
>>> unsigned a = ~0;
>>> unsigned b = (a>> 22) & 1;
>>> unsigned c = (a << 22)>> 31;
>>> printf("%x %x\n", b, c);
>>> return 0;
>>> }
>>> 
>>> both print 1. So I remain a bit uncertain.
>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>> I might dig more before commiting the undo.
>>> Maybe bit fields of multiple bits are the only ones broken.
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> 
>>>> 
>>>> Tony I think it is your change to extract_mn.
>>>> Try it with SOLsun for example.
>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>> 
>>>> 
>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>> 77,78c77,78
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>>> 118,119c118,119
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>>> 197,198c197,198
>>>> < srl %g1, 21, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 21, %g1
>>>>> srl %g1, 31, %g1
>>>> 236,237c236,237
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>>> 273,274c273,274
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> 
>>>> 
>>>> This is not optimized.
>>>> They seem equally optimal, but very different.
>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>> srl+and is clearer.
>>>> I don't remember which of these worked.
>>>> 
>>>> 
>>>> < srl %g1, 22, %g1
>>>> 
>>>> < and %g1, 1, %g1
>>>> 
>>>> ---
>>>> 
>>>>> sll %g1, 22, %g1
>>>> 
>>>>> srl %g1, 31, %g1
>>>> 
>>>> 
>>>> 
>>>> I read the first as:
>>>> extract bit 22, plus or minus 1
>>>> vs.
>>>> extract bit 32-22=10, plus or minus 1.
>>>> 
>>>> 
>>>> It would probably be ok to move bits around, but insert would have to match.
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> 
>>>>> 
>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>> 
>>>>>> 
>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>> 
>>>>>> 
>>>>>> I have some extra time today, so, plan:
>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>> work through the others if not
>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>> touch it again, which is fine. :) )
>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>> if others are ruled out I'll undo or test it.
>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>> it appeared to be a very convenient coincidence.)
>>>>>> 
>>>>>> 
>>>>>> I am surprised that I386_* working and broken.
>>>>>> I would think wordsize and endian is all that matters here.
>>>>>> 
>>>>>> 
>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> 
>>>>>>> 
>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>> I agree if they drop it, we have to.
>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>> but that's not likely.
>>>>>>> A C generating backend also solves this.
>>>>>>> 
>>>>>>> 
>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>> 
>>>>>>> 
>>>>>>> I don't remember about div/mod.
>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>> 
>>>>>>> 
>>>>>>> I'm also not optimizing at all.
>>>>>>> 
>>>>>>> 
>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>> 
>>>>>>> 
>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>> 
>>>>>>> 
>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>> 
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> 
>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>> 
>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>> 
>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>> 
>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>> - my changes to set operations
>>>>>>>>> - my change to div/mod
>>>>>>>>> - Tony's to bit field operations
>>>>>>>>> 
>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>> 
>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>> to keep them if they don't work.
>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>> 
>>>>>>>>> - Jay
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>> 
>>>>>>>>>> - Jay
>>>>>>>>>> 
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>> 
>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>> 
>>>>>>>>>>> - Jay
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Sat May 15 07:57:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 05:57:27 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , ,
	,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , ,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , ,
	,,<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, ,
	,,<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>,
	, , <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
Message-ID: <COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>


I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
And that bit offsets are interpreted differently for big endian and little endian.
? I can NOT confirm that I386_LINUX was broken.
? As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.


I happen to then try a bunch of big endian platforms.


Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
but I think it is fairly easy to come up with structs without bitfields with the "same" layout
across all architectures, at least for a given wordsize/endian.)


I should admit something.
When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
Lately for this reason I've been removing them from code where I can.
Clearly they have a place, where compactness of data is of the prime importance.


It's possible this is just me, that more expert programmers can readily imagine just how
bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
therefore they can determine the layout from glancing at the declaration.


I just can't imagine what would be obvious.
Simple example:

typedef union {
? unsigned AsInt32;
? struct { unsigned a : 1 } Bits;
} T1;


T1 t;
t.Bits.a = 1;


printf("%x\n", t.AsInt32);


prints 1 or 0x80000000 or what?


It could be there are obvious rules, and they are endian dependent, but that otherwise
all ABIs and compilers define them the same.
If that is the case, I think we could get something more "optimal".
However, notice how similar the "optimized" code was.
And we could easily generate that without a bitfield ref.
?Just shift right and and with a constant, instead of shift left and then right.


Could be that the decision is target-dependent as to what is optimal though.


?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:14:54 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>
>
> On 14 May 2010, at 23:10, Jay K wrote:
>
>>
>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>
>> BIT_FIELD_REF considered harmful
>>
>> We should try to use COMPONENT_REF instead.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>> A more accurate one, which shows a problem, is:
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> But I'm still having trouble convincing myself.
>>> I guess the second might give you the 10th bit.
>>> Er, the 9th.
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>>
>>> a = 1 << 9;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> 1 0
>>> 0 1
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>
>>>> Er.
>>>> first: a = (a>> 22) & 1;
>>>> second: a = (a << 22)>> 31;
>>>>
>>>> are actually darn close, maybe the same.
>>>> Let's just be lame and test in C:
>>>>
>>>> #include
>>>> int main()
>>>> {
>>>> unsigned a = ~0;
>>>> unsigned b = (a>> 22) & 1;
>>>> unsigned c = (a << 22)>> 31;
>>>> printf("%x %x\n", b, c);
>>>> return 0;
>>>> }
>>>>
>>>> both print 1. So I remain a bit uncertain.
>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>> I might dig more before commiting the undo.
>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Tony I think it is your change to extract_mn.
>>>>> Try it with SOLsun for example.
>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>
>>>>>
>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>> 77,78c77,78
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 118,119c118,119
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 197,198c197,198
>>>>> < srl %g1, 21, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 21, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 236,237c236,237
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 273,274c273,274
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>>
>>>>>
>>>>> This is not optimized.
>>>>> They seem equally optimal, but very different.
>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>> srl+and is clearer.
>>>>> I don't remember which of these worked.
>>>>>
>>>>>
>>>>> < srl %g1, 22, %g1
>>>>>
>>>>> < and %g1, 1, %g1
>>>>>
>>>>> ---
>>>>>
>>>>>> sll %g1, 22, %g1
>>>>>
>>>>>> srl %g1, 31, %g1
>>>>>
>>>>>
>>>>>
>>>>> I read the first as:
>>>>> extract bit 22, plus or minus 1
>>>>> vs.
>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>
>>>>>
>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>
>>>>>>>
>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>
>>>>>>>
>>>>>>> I have some extra time today, so, plan:
>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>> work through the others if not
>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>> touch it again, which is fine. :) )
>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>
>>>>>>>
>>>>>>> I am surprised that I386_* working and broken.
>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>
>>>>>>>
>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>> I agree if they drop it, we have to.
>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>> but that's not likely.
>>>>>>>> A C generating backend also solves this.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't remember about div/mod.
>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm also not optimizing at all.
>>>>>>>>
>>>>>>>>
>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>
>>>>>>>>
>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>
>>>>>>>>
>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>
>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>
>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>
>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>> - my changes to set operations
>>>>>>>>>> - my change to div/mod
>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>
>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>
>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 07:58:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 05:58:57 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , ,
	,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , ,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , ,
	,,<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, ,
	,,<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>,
	, , <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
Message-ID: <COL101-W188664168A5CE39254D0F5E6FE0@phx.gbl>


> COMPONENT_REF is difficult because of the lack of type info I think
That's what I thought.
It's unfortunate imho.
We could probably do better fairly easily. ?
? Heck, with the possible major upside of having gdb work? (I don't mean m3gdb).
I'm still bothered by the problem I had on OpenBSD/mips64 where a "bitfield ref" with a high byte offset
was treated incorrectly by the compiler, where a component ref would surely have worked.

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:14:54 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>
>
> On 14 May 2010, at 23:10, Jay K wrote:
>
>>
>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>
>> BIT_FIELD_REF considered harmful
>>
>> We should try to use COMPONENT_REF instead.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>> A more accurate one, which shows a problem, is:
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> But I'm still having trouble convincing myself.
>>> I guess the second might give you the 10th bit.
>>> Er, the 9th.
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>>
>>> a = 1 << 9;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> 1 0
>>> 0 1
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>
>>>> Er.
>>>> first: a = (a>> 22) & 1;
>>>> second: a = (a << 22)>> 31;
>>>>
>>>> are actually darn close, maybe the same.
>>>> Let's just be lame and test in C:
>>>>
>>>> #include
>>>> int main()
>>>> {
>>>> unsigned a = ~0;
>>>> unsigned b = (a>> 22) & 1;
>>>> unsigned c = (a << 22)>> 31;
>>>> printf("%x %x\n", b, c);
>>>> return 0;
>>>> }
>>>>
>>>> both print 1. So I remain a bit uncertain.
>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>> I might dig more before commiting the undo.
>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Tony I think it is your change to extract_mn.
>>>>> Try it with SOLsun for example.
>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>
>>>>>
>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>> 77,78c77,78
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 118,119c118,119
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 197,198c197,198
>>>>> < srl %g1, 21, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 21, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 236,237c236,237
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 273,274c273,274
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>>
>>>>>
>>>>> This is not optimized.
>>>>> They seem equally optimal, but very different.
>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>> srl+and is clearer.
>>>>> I don't remember which of these worked.
>>>>>
>>>>>
>>>>> < srl %g1, 22, %g1
>>>>>
>>>>> < and %g1, 1, %g1
>>>>>
>>>>> ---
>>>>>
>>>>>> sll %g1, 22, %g1
>>>>>
>>>>>> srl %g1, 31, %g1
>>>>>
>>>>>
>>>>>
>>>>> I read the first as:
>>>>> extract bit 22, plus or minus 1
>>>>> vs.
>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>
>>>>>
>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>
>>>>>>>
>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>
>>>>>>>
>>>>>>> I have some extra time today, so, plan:
>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>> work through the others if not
>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>> touch it again, which is fine. :) )
>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>
>>>>>>>
>>>>>>> I am surprised that I386_* working and broken.
>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>
>>>>>>>
>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>> I agree if they drop it, we have to.
>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>> but that's not likely.
>>>>>>>> A C generating backend also solves this.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't remember about div/mod.
>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm also not optimizing at all.
>>>>>>>>
>>>>>>>>
>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>
>>>>>>>>
>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>
>>>>>>>>
>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>
>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>
>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>
>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>> - my changes to set operations
>>>>>>>>>> - my change to div/mod
>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>
>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>
>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 09:03:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 07:03:53 +0000
Subject: [M3devel] random.longint()?
Message-ID: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>


In libm3 there is random number generation.
In libm3 that is code that wants 8 random bytes.
? If integer is 4 bytes, it calls random.integer() twice, else if it is 8, once.

It seems natural that we should provide random.longint()?

And then the other code can just use it?

Someone can look into the random number generator and
?- make sure it is actually "correct" for 64bit integer?
?- and if so, change the lowest level to use LONGINT
?? and layer integer over it? -- not sure how, presumably
?? taking only the lower 32bits loses too much randomness?


This is what I get for looking into why we are ever asked to extract 0 bits..

"Everywhere I look, I see bugs." (topic of a separate mail)

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Sat May 15 09:08:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 07:08:03 +0000
Subject: [M3devel] libm3/Swap?
Message-ID: <COL101-W58DAAF4635345A955820B5E6FE0@phx.gbl>


libm3/.../swap.m3:


FROM Word IMPORT Or, And, Not, LeftShift, RightShift, Extract;


CONST
? B0 = 16_FF;
? B1 = 16_FF00;
? B2 = 16_FF0000;
? B3 = 16_FF000000;


? (* These will all be zero on machines with BYTESIZE(INTEGER) = 32 *)
? B4 = LeftShift(B3, 8);
? B5 = LeftShift(B4, 8);
? B6 = LeftShift(B5, 8);
? B7 = LeftShift(B6, 8);

CONST SignExt32 = ARRAY [0..1] OF Word.T {0, Not(16_FFFFFFFF)};

(* Swaps the lower 4 bytes of i *)
PROCEDURE Swap4 (i: Int32): Int32 =
? BEGIN
??? IF BYTESIZE(INTEGER) = 4 THEN
????? RETURN Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
??????????????? Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24)));
??? ELSIF BYTESIZE(INTEGER) = 8 THEN
????? RETURN
??????? Or(SignExt32[Extract(i, 7, 1)],
?????????? Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
????????????? Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24))));
??? ELSE
????? RAISE Failure;
??? END;
? END Swap4;


What is the meaning of the 7?
? In Extract(i, 7, 1)?
Presumably it should be 63??
I guess I'll write a test..


Is there a better idiom that doesn't expose? architectures to compile code for other word sizes?
Maybe fork the file and include_dir(WORD_SIZE)?
?Like is done in m3core/src/C?
?

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 11:24:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 09:24:02 +0000
Subject: [M3devel] libm3/Swap?
Message-ID: <COL101-W64EAAFCE37D8755D457662E6FE0@phx.gbl>


Oh I see, it is sign extending the result, not copying the sign from the original.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: libm3/Swap?
> Date: Sat, 15 May 2010 07:08:03 +0000
>
>
> libm3/.../swap.m3:
>
>
> FROM Word IMPORT Or, And, Not, LeftShift, RightShift, Extract;
>
>
> CONST
>   B0 = 16_FF;
>   B1 = 16_FF00;
>   B2 = 16_FF0000;
>   B3 = 16_FF000000;
>
>
>   (* These will all be zero on machines with BYTESIZE(INTEGER) = 32 *)
>   B4 = LeftShift(B3, 8);
>   B5 = LeftShift(B4, 8);
>   B6 = LeftShift(B5, 8);
>   B7 = LeftShift(B6, 8);
>
> CONST SignExt32 = ARRAY [0..1] OF Word.T {0, Not(16_FFFFFFFF)};
>
> (* Swaps the lower 4 bytes of i *)
> PROCEDURE Swap4 (i: Int32): Int32 =
>   BEGIN
>     IF BYTESIZE(INTEGER) = 4 THEN
>       RETURN Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
>                 Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24)));
>     ELSIF BYTESIZE(INTEGER) = 8 THEN
>       RETURN
>         Or(SignExt32[Extract(i, 7, 1)],
>            Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
>               Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24))));
>     ELSE
>       RAISE Failure;
>     END;
>   END Swap4;
>
>
> What is the meaning of the 7?
>   In Extract(i, 7, 1)?
> Presumably it should be 63??
> I guess I'll write a test..
>
>
> Is there a better idiom that doesn't expose  architectures to compile code for other word sizes?
> Maybe fork the file and include_dir(WORD_SIZE)?
>  Like is done in m3core/src/C?
>
>
>  - Jay
>
 		 	   		  

From hosking at cs.purdue.edu  Sat May 15 18:36:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 12:36:25 -0400
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>
Message-ID: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>

I hesitate to slow down the default implementation of random by using LONGINT (slow) instead of INTEGER (fast).

On 15 May 2010, at 03:03, Jay K wrote:

> 
> In libm3 there is random number generation.
> In libm3 that is code that wants 8 random bytes.
>   If integer is 4 bytes, it calls random.integer() twice, else if it is 8, once.
> 
> It seems natural that we should provide random.longint()?
> 
> And then the other code can just use it?
> 
> Someone can look into the random number generator and
>  - make sure it is actually "correct" for 64bit integer?
>  - and if so, change the lowest level to use LONGINT
>    and layer integer over it? -- not sure how, presumably
>    taking only the lower 32bits loses too much randomness?
> 
> 
> This is what I get for looking into why we are ever asked to extract 0 bits..
> 
> "Everywhere I look, I see bugs." (topic of a separate mail)
> 
>  - Jay
> 
> 		 	   		  



From jay.krell at cornell.edu  Sun May 16 01:22:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 23:22:42 +0000
Subject: [M3devel] random.longint()?
In-Reply-To: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>,
	<DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
Message-ID: <COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>


Fair enough. I guess random.longint() could just call random.integer() twice, or clients could, existing situation, do nothing.

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 12:36:25 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] random.longint()?
>
> I hesitate to slow down the default implementation of random by using LONGINT (slow) instead of INTEGER (fast).
>
> On 15 May 2010, at 03:03, Jay K wrote:
>
>>
>> In libm3 there is random number generation.
>> In libm3 that is code that wants 8 random bytes.
>> If integer is 4 bytes, it calls random.integer() twice, else if it is 8, once.
>>
>> It seems natural that we should provide random.longint()?
>>
>> And then the other code can just use it?
>>
>> Someone can look into the random number generator and
>> - make sure it is actually "correct" for 64bit integer?
>> - and if so, change the lowest level to use LONGINT
>> and layer integer over it? -- not sure how, presumably
>> taking only the lower 32bits loses too much randomness?
>>
>>
>> This is what I get for looking into why we are ever asked to extract 0 bits..
>>
>> "Everywhere I look, I see bugs." (topic of a separate mail)
>>
>> - Jay
>>
>>
>
 		 	   		  

From rodney_bates at lcwb.coop  Sun May 16 03:59:18 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 15 May 2010 20:59:18 -0500
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
 SPARC64_SOLARIS)
In-Reply-To: <COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , , ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , , ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, , ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
	<COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>
Message-ID: <4BEF5176.5020503@lcwb.coop>



Jay K wrote:
> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
> And that bit offsets are interpreted differently for big endian and little endian.
>   I can NOT confirm that I386_LINUX was broken.
>   As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
> 
> 
> I happen to then try a bunch of big endian platforms.
> 
> 
> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
> across all architectures, at least for a given wordsize/endian.)
> 
> 
> I should admit something.
> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
> Lately for this reason I've been removing them from code where I can.
> Clearly they have a place, where compactness of data is of the prime importance.
> 
> 
> It's possible this is just me, that more expert programmers can readily imagine just how
> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
> therefore they can determine the layout from glancing at the declaration.
> 

According to my C '99 standard, just about everything about bit field layout is
implementation-defined, except for the bit count of each field.  Harbison and
Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
using bit-twiddling operators instead of bit fields.  Failing that, they recommend
doing experiments with your particular compiler to verify your assumptions.  Obviously
not possible for portable code.

They do suggest that the fields will likely be laid out right-to-left on a little-endian
machine and conversely.  But even there, it matters what size of "unit" is laid out
this way (a native word, for example) before moving on to the next unit, and that
is also implementation-defined.


> 
> I just can't imagine what would be obvious.
> Simple example:
> 
> typedef union {
>   unsigned AsInt32;
>   struct { unsigned a : 1 } Bits;
> } T1;
> 
> 
> T1 t;
> t.Bits.a = 1;
> 
> 
> printf("%x\n", t.AsInt32);
> 
> 
> prints 1 or 0x80000000 or what?
> 
> 
> It could be there are obvious rules, and they are endian dependent, but that otherwise
> all ABIs and compilers define them the same.
> If that is the case, I think we could get something more "optimal".
> However, notice how similar the "optimized" code was.
> And we could easily generate that without a bitfield ref.
>  Just shift right and and with a constant, instead of shift left and then right.
> 
> 
> Could be that the decision is target-dependent as to what is optimal though.
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 00:14:54 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>
>>
>> On 14 May 2010, at 23:10, Jay K wrote:
>>
>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>
>>> BIT_FIELD_REF considered harmful
>>>
>>> We should try to use COMPONENT_REF instead.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>> A more accurate one, which shows a problem, is:
>>>>
>>>> #include
>>>>
>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>
>>>> int main()
>>>> {
>>>> unsigned a = 1 << 22;
>>>> printf("%x %x\n", F1(a), F2(a));
>>>> return 0;
>>>> }
>>>>
>>>> But I'm still having trouble convincing myself.
>>>> I guess the second might give you the 10th bit.
>>>> Er, the 9th.
>>>>
>>>> #include
>>>>
>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>
>>>> int main()
>>>> {
>>>> unsigned a = 1 << 22;
>>>> printf("%x %x\n", F1(a), F2(a));
>>>>
>>>> a = 1 << 9;
>>>> printf("%x %x\n", F1(a), F2(a));
>>>> return 0;
>>>> }
>>>>
>>>> 1 0
>>>> 0 1
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>> Er.
>>>>> first: a = (a>> 22) & 1;
>>>>> second: a = (a << 22)>> 31;
>>>>>
>>>>> are actually darn close, maybe the same.
>>>>> Let's just be lame and test in C:
>>>>>
>>>>> #include
>>>>> int main()
>>>>> {
>>>>> unsigned a = ~0;
>>>>> unsigned b = (a>> 22) & 1;
>>>>> unsigned c = (a << 22)>> 31;
>>>>> printf("%x %x\n", b, c);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> both print 1. So I remain a bit uncertain.
>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>> I might dig more before commiting the undo.
>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Tony I think it is your change to extract_mn.
>>>>>> Try it with SOLsun for example.
>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>
>>>>>>
>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>> 77,78c77,78
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 118,119c118,119
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 197,198c197,198
>>>>>> < srl %g1, 21, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 21, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 236,237c236,237
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 273,274c273,274
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>>
>>>>>>
>>>>>> This is not optimized.
>>>>>> They seem equally optimal, but very different.
>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>> srl+and is clearer.
>>>>>> I don't remember which of these worked.
>>>>>>
>>>>>>
>>>>>> < srl %g1, 22, %g1
>>>>>>
>>>>>> < and %g1, 1, %g1
>>>>>>
>>>>>> ---
>>>>>>
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>>
>>>>>>
>>>>>> I read the first as:
>>>>>> extract bit 22, plus or minus 1
>>>>>> vs.
>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>
>>>>>>
>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>
>>>>>>>>
>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>
>>>>>>>>
>>>>>>>> I have some extra time today, so, plan:
>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>> work through the others if not
>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>> touch it again, which is fine. :) )
>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>
>>>>>>>>
>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>
>>>>>>>>
>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>> but that's not likely.
>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't remember about div/mod.
>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>
>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>
>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>
>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>
>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>
>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>
>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>
>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>
>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>  		 	   		  


From hendrik at topoi.pooq.com  Sun May 16 01:05:51 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 15 May 2010 19:05:51 -0400
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
References: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
	<COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
Message-ID: <20100515230551.GA24444@topoi.pooq.com>

On Sat, May 15, 2010 at 11:22:42PM +0000, Jay K wrote:
> 
> Fair enough. I guess random.longint() could just call random.integer() twice, or clients could, existing situation, do nothing.

Just how many bits of state does the random number generator have?

-- hendrik


From jay.krell at cornell.edu  Sun May 16 06:36:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 16 May 2010 04:36:21 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
 SPARC64_SOLARIS)
In-Reply-To: <4BEF5176.5020503@lcwb.coop>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , ,
	,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , ,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , ,
	,,<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , ,
	,,<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, ,
	,,<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>,
	, , <COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>, ,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>, ,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>,
	<COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>,
	<4BEF5176.5020503@lcwb.coop>
Message-ID: <COL101-W228E73F7491802AFD3D41AE6FF0@phx.gbl>


> They do suggest that the fields will likely be laid out right-to-left
> on a little-endian machine and conversely.  But even there, it matters
> what size of "unit" is laid out this way (a native word, for example)
> before moving on to the next unit, and that is also implementation-defined.
 
This is what I was alluding to.
Even though the rules are explicitly compiler-dependent, it could be
that to all compiler writers, such as their shared mindset may be,
there are fairly obvious rules to adopt
and they pretty much all adopt the same ones. I don't know.

Not "all compilers", but "gcc on all platforms".

I suspect that if we said like:
#if TARGET_BIG_ENDIAN /* or !TARGET_LITTLE_ENDIAN, one of these probably exists */
  m = TYPE_PRECISION(t) - m.
#endif

it'd work.


Anyway, I put the code back.


It would also be a good idea to consistently used bitfields for all insert/extract
forms, instead of just one extract form. That would provide consistency.
But we also use extract in other places, e.g. division.
 So consistency between insert and extract isn't actually sufficient.


We do use bitfields in an odd way -- for all loads and stores,
that either have a non-zero offset or that do a type conversion,
and it bugs me.


There is something in gcc that decides if you are offseting
more than a word into something only a word size, throw out the offset,
or somesuch. OpenBSD/mips64 used to incorrectly access all "globals".
"Globals" are defined by parse.c as just a block of memory
with a name for its start, and..we don't know the size, so before
we said it is arbitrarily small, like a word, as a workaround I
declare that it is a arbitrarily less small:


static void
m3cg_declare_segment (void)
{
...
  /* we really don't have an idea of what the type of this var is; let's try
     to put something that will be good enough for all the uses of this var we
     are going to see before we have a bind_segment. Use a large size so that
     gcc doesn't think it fits in a register, so that loads out of it do get
     their offsets applied. */
  TREE_TYPE (v)
    = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);
  layout_decl (v, BIGGEST_ALIGNMENT);


We do actually know the size though.
The thing could be declared to be a record with typed fields
 and we could use "component refs", except we don't bother
 passing enough information along.
It's related to what Tony and I said yesterday.


(OpenBSD/mips64 isn't known to fully work anyway.
But MIPS is making a comeback, see:
http://www.openbsd.org/loongson.html
http://www.lemote.com/en/products/all-in-one/2010/0311/122.html
http://www.lemote.com/en/products/Notebook/2010/0310/112.html
etc.
)

?- Jay

----------------------------------------
> Date: Sat, 15 May 2010 20:59:18 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
>
> Jay K wrote:
>> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
>> And that bit offsets are interpreted differently for big endian and little endian.
>> I can NOT confirm that I386_LINUX was broken.
>> As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
>>
>>
>> I happen to then try a bunch of big endian platforms.
>>
>>
>> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
>> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
>> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
>> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
>> across all architectures, at least for a given wordsize/endian.)
>>
>>
>> I should admit something.
>> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
>> Lately for this reason I've been removing them from code where I can.
>> Clearly they have a place, where compactness of data is of the prime importance.
>>
>>
>> It's possible this is just me, that more expert programmers can readily imagine just how
>> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
>> therefore they can determine the layout from glancing at the declaration.
>>
>
> According to my C '99 standard, just about everything about bit field layout is
> implementation-defined, except for the bit count of each field. Harbison and
> Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
> using bit-twiddling operators instead of bit fields. Failing that, they recommend
> doing experiments with your particular compiler to verify your assumptions. Obviously
> not possible for portable code.
>
> They do suggest that the fields will likely be laid out right-to-left on a little-endian
> machine and conversely. But even there, it matters what size of "unit" is laid out
> this way (a native word, for example) before moving on to the next unit, and that
> is also implementation-defined.
>
>
>>
>> I just can't imagine what would be obvious.
>> Simple example:
>>
>> typedef union {
>> unsigned AsInt32;
>> struct { unsigned a : 1 } Bits;
>> } T1;
>>
>>
>> T1 t;
>> t.Bits.a = 1;
>>
>>
>> printf("%x\n", t.AsInt32);
>>
>>
>> prints 1 or 0x80000000 or what?
>>
>>
>> It could be there are obvious rules, and they are endian dependent, but that otherwise
>> all ABIs and compilers define them the same.
>> If that is the case, I think we could get something more "optimal".
>> However, notice how similar the "optimized" code was.
>> And we could easily generate that without a bitfield ref.
>> Just shift right and and with a constant, instead of shift left and then right.
>>
>>
>> Could be that the decision is target-dependent as to what is optimal though.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 00:14:54 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>>
>>>
>>> On 14 May 2010, at 23:10, Jay K wrote:
>>>
>>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>>
>>>> BIT_FIELD_REF considered harmful
>>>>
>>>> We should try to use COMPONENT_REF instead.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>>> A more accurate one, which shows a problem, is:
>>>>>
>>>>> #include
>>>>>
>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>
>>>>> int main()
>>>>> {
>>>>> unsigned a = 1 << 22;
>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>> return 0;
>>>>> }
>>>>>
>>>>> But I'm still having trouble convincing myself.
>>>>> I guess the second might give you the 10th bit.
>>>>> Er, the 9th.
>>>>>
>>>>> #include
>>>>>
>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>
>>>>> int main()
>>>>> {
>>>>> unsigned a = 1 << 22;
>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>
>>>>> a = 1 << 9;
>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>> return 0;
>>>>> }
>>>>>
>>>>> 1 0
>>>>> 0 1
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>> Er.
>>>>>> first: a = (a>> 22) & 1;
>>>>>> second: a = (a << 22)>> 31;
>>>>>>
>>>>>> are actually darn close, maybe the same.
>>>>>> Let's just be lame and test in C:
>>>>>>
>>>>>> #include
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = ~0;
>>>>>> unsigned b = (a>> 22) & 1;
>>>>>> unsigned c = (a << 22)>> 31;
>>>>>> printf("%x %x\n", b, c);
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> both print 1. So I remain a bit uncertain.
>>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>>> I might dig more before commiting the undo.
>>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> Tony I think it is your change to extract_mn.
>>>>>>> Try it with SOLsun for example.
>>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>>
>>>>>>>
>>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>>> 77,78c77,78
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 118,119c118,119
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 197,198c197,198
>>>>>>> < srl %g1, 21, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 21, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 236,237c236,237
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 273,274c273,274
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>>
>>>>>>>
>>>>>>> This is not optimized.
>>>>>>> They seem equally optimal, but very different.
>>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>>> srl+and is clearer.
>>>>>>> I don't remember which of these worked.
>>>>>>>
>>>>>>>
>>>>>>> < srl %g1, 22, %g1
>>>>>>>
>>>>>>> < and %g1, 1, %g1
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>>
>>>>>>>
>>>>>>> I read the first as:
>>>>>>> extract bit 22, plus or minus 1
>>>>>>> vs.
>>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>>
>>>>>>>
>>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have some extra time today, so, plan:
>>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>>> work through the others if not
>>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>>> touch it again, which is fine. :) )
>>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>>> but that's not likely.
>>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't remember about div/mod.
>>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>>
>>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>>
>>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>>
>>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>>
>>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>>
>>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>>
>>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>
 		 	   		  

From rodney_bates at lcwb.coop  Sun May 16 19:53:13 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 16 May 2010 12:53:13 -0500
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
 SPARC64_SOLARIS)
In-Reply-To: <COL101-W228E73F7491802AFD3D41AE6FF0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , , , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , , , ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , , , ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, , , ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, , ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>, ,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>, ,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>,
	<COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>,
	<4BEF5176.5020503@lcwb.coop>
	<COL101-W228E73F7491802AFD3D41AE6FF0@phx.gbl>
Message-ID: <4BF03109.1050704@lcwb.coop>



Jay K wrote:
>> They do suggest that the fields will likely be laid out right-to-left
>> on a little-endian machine and conversely.  But even there, it matters
>> what size of "unit" is laid out this way (a native word, for example)
>> before moving on to the next unit, and that is also implementation-defined.
>  
> This is what I was alluding to.
> Even though the rules are explicitly compiler-dependent, it could be
> that to all compiler writers, such as their shared mindset may be,
> there are fairly obvious rules to adopt
> and they pretty much all adopt the same ones. I don't know.
> 
> Not "all compilers", but "gcc on all platforms".
> 
> I suspect that if we said like:
> #if TARGET_BIG_ENDIAN /* or !TARGET_LITTLE_ENDIAN, one of these probably exists */
>   m = TYPE_PRECISION(t) - m.
> #endif
> 
> it'd work.
> 
> 
> Anyway, I put the code back.
> 
> 
> It would also be a good idea to consistently used bitfields for all insert/extract
> forms, instead of just one extract form. That would provide consistency.
> But we also use extract in other places, e.g. division.
>  So consistency between insert and extract isn't actually sufficient.

Ah, are you talking about bit field _operators_ in the intermediate form
generated by parse.c to gcc?  These could well be a different animal
from C source code bit fields.  Or perhaps the C front end does a direct
translation, but gcc has well-defined semantics for them.  I would expect
these would follow a consistent pattern, for gcc.  Might have to do some
heavy code reading to infer it.

> 
> 
> We do use bitfields in an odd way -- for all loads and stores,
> that either have a non-zero offset or that do a type conversion,
> and it bugs me.
> 
> 
> There is something in gcc that decides if you are offseting
> more than a word into something only a word size, throw out the offset,
> or somesuch. OpenBSD/mips64 used to incorrectly access all "globals".
> "Globals" are defined by parse.c as just a block of memory
> with a name for its start, and..we don't know the size, so before
> we said it is arbitrarily small, like a word, as a workaround I
> declare that it is a arbitrarily less small:
> 
> 
> static void
> m3cg_declare_segment (void)
> {
> ...
>   /* we really don't have an idea of what the type of this var is; let's try
>      to put something that will be good enough for all the uses of this var we
>      are going to see before we have a bind_segment. Use a large size so that
>      gcc doesn't think it fits in a register, so that loads out of it do get
>      their offsets applied. */
>   TREE_TYPE (v)
>     = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);
>   layout_decl (v, BIGGEST_ALIGNMENT);
> 
> 
> We do actually know the size though.
> The thing could be declared to be a record with typed fields
>  and we could use "component refs", except we don't bother
>  passing enough information along.
> It's related to what Tony and I said yesterday.
> 
> 
> (OpenBSD/mips64 isn't known to fully work anyway.
> But MIPS is making a comeback, see:
> http://www.openbsd.org/loongson.html
> http://www.lemote.com/en/products/all-in-one/2010/0311/122.html
> http://www.lemote.com/en/products/Notebook/2010/0310/112.html
> etc.
> )
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Sat, 15 May 2010 20:59:18 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>>
>> Jay K wrote:
>>> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
>>> And that bit offsets are interpreted differently for big endian and little endian.
>>> I can NOT confirm that I386_LINUX was broken.
>>> As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
>>>
>>>
>>> I happen to then try a bunch of big endian platforms.
>>>
>>>
>>> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
>>> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
>>> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
>>> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
>>> across all architectures, at least for a given wordsize/endian.)
>>>
>>>
>>> I should admit something.
>>> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
>>> Lately for this reason I've been removing them from code where I can.
>>> Clearly they have a place, where compactness of data is of the prime importance.
>>>
>>>
>>> It's possible this is just me, that more expert programmers can readily imagine just how
>>> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
>>> therefore they can determine the layout from glancing at the declaration.
>>>
>> According to my C '99 standard, just about everything about bit field layout is
>> implementation-defined, except for the bit count of each field. Harbison and
>> Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
>> using bit-twiddling operators instead of bit fields. Failing that, they recommend
>> doing experiments with your particular compiler to verify your assumptions. Obviously
>> not possible for portable code.
>>
>> They do suggest that the fields will likely be laid out right-to-left on a little-endian
>> machine and conversely. But even there, it matters what size of "unit" is laid out
>> this way (a native word, for example) before moving on to the next unit, and that
>> is also implementation-defined.
>>
>>
>>> I just can't imagine what would be obvious.
>>> Simple example:
>>>
>>> typedef union {
>>> unsigned AsInt32;
>>> struct { unsigned a : 1 } Bits;
>>> } T1;
>>>
>>>
>>> T1 t;
>>> t.Bits.a = 1;
>>>
>>>
>>> printf("%x\n", t.AsInt32);
>>>
>>>
>>> prints 1 or 0x80000000 or what?
>>>
>>>
>>> It could be there are obvious rules, and they are endian dependent, but that otherwise
>>> all ABIs and compilers define them the same.
>>> If that is the case, I think we could get something more "optimal".
>>> However, notice how similar the "optimized" code was.
>>> And we could easily generate that without a bitfield ref.
>>> Just shift right and and with a constant, instead of shift left and then right.
>>>
>>>
>>> Could be that the decision is target-dependent as to what is optimal though.
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 00:14:54 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>>>
>>>>
>>>> On 14 May 2010, at 23:10, Jay K wrote:
>>>>
>>>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>>>
>>>>> BIT_FIELD_REF considered harmful
>>>>>
>>>>> We should try to use COMPONENT_REF instead.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>>>> A more accurate one, which shows a problem, is:
>>>>>>
>>>>>> #include
>>>>>>
>>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = 1 << 22;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> But I'm still having trouble convincing myself.
>>>>>> I guess the second might give you the 10th bit.
>>>>>> Er, the 9th.
>>>>>>
>>>>>> #include
>>>>>>
>>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = 1 << 22;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>>
>>>>>> a = 1 << 9;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> 1 0
>>>>>> 0 1
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>> Er.
>>>>>>> first: a = (a>> 22) & 1;
>>>>>>> second: a = (a << 22)>> 31;
>>>>>>>
>>>>>>> are actually darn close, maybe the same.
>>>>>>> Let's just be lame and test in C:
>>>>>>>
>>>>>>> #include
>>>>>>> int main()
>>>>>>> {
>>>>>>> unsigned a = ~0;
>>>>>>> unsigned b = (a>> 22) & 1;
>>>>>>> unsigned c = (a << 22)>> 31;
>>>>>>> printf("%x %x\n", b, c);
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> both print 1. So I remain a bit uncertain.
>>>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>>>> I might dig more before commiting the undo.
>>>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> Tony I think it is your change to extract_mn.
>>>>>>>> Try it with SOLsun for example.
>>>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>>>
>>>>>>>>
>>>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>>>> 77,78c77,78
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 118,119c118,119
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 197,198c197,198
>>>>>>>> < srl %g1, 21, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 21, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 236,237c236,237
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 273,274c273,274
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>>
>>>>>>>>
>>>>>>>> This is not optimized.
>>>>>>>> They seem equally optimal, but very different.
>>>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>>>> srl+and is clearer.
>>>>>>>> I don't remember which of these worked.
>>>>>>>>
>>>>>>>>
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>>
>>>>>>>> < and %g1, 1, %g1
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>>
>>>>>>>> I read the first as:
>>>>>>>> extract bit 22, plus or minus 1
>>>>>>>> vs.
>>>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>>>
>>>>>>>>
>>>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have some extra time today, so, plan:
>>>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>>>> work through the others if not
>>>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>>>> touch it again, which is fine. :) )
>>>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>>>> but that's not likely.
>>>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't remember about div/mod.
>>>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>>>
>>>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>  		 	   		  


From hendrik at topoi.pooq.com  Wed May 19 22:54:11 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 19 May 2010 16:54:11 -0400
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
References: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
	<COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
Message-ID: <20100519205411.GA18956@topoi.pooq.com>

On Sat, May 15, 2010 at 11:22:42PM +0000, Jay K wrote:
> 
> Fair enough. I guess random.longint() could just call random.integer() twice, or clients could, existing situation, do nothing.

I don't know how many bits of state the prwudorandom number generator 
uses, but is it has the usual 32 bits, calling random.integer() twice to 
get 64 bits does *not* give properly randome 64-bi strings.

-- hendrik


From dragisha at m3w.org  Thu May 20 12:08:53 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 20 May 2010 12:08:53 +0200
Subject: [M3devel] Linux/ARM? Android?
Message-ID: <1274350133.8902.0.camel@localhost>

As per subject... What is status of Linux/ARM port of Modula-3 and
chances for Android port?
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu May 20 13:47:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 11:47:56 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <1274350133.8902.0.camel@localhost>
References: <1274350133.8902.0.camel@localhost>
Message-ID: <COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>


Status is roughly nowhere.
Chances are not bad though.
There is very little work to do when the system supports posix and gcc supports the system, and that describes a lot of systems.
? Try this: cd scripts/python && ./boot1.py ARM_LINUX 


Give me ssh access to a device?
?Or maybe there is emulator?


I've had a PogoPlug (Linux/ARM) for over a year, haven't touched it.
And some I think Linux/ARM LaCie network drive also.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Thu, 20 May 2010 12:08:53 +0200
> Subject: [M3devel] Linux/ARM? Android?
>
> As per subject... What is status of Linux/ARM port of Modula-3 and
> chances for Android port?
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 13:50:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 11:50:50 +0000
Subject: [M3devel] gcc 4.5.0?
Message-ID: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>


Tony, what is involved in upgrading to gcc 4.5.0?

Import unchanged gcc.4-5.0 to the "gcc-releases" branch?

Merge it to the "gcc" branch?

And then to head?




I mean, you know..there are all the directions out there for managing
external trees, but I think the main missing detail is what
branches/tag names to use to match previous history, and it isn't
immediately clear to me..from, um, reading the history (which imho is
yet another indictment of CVS -- I can't figure out what happened).


I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
But I haven't ever updated it.
e.g. cvsup.


I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
The diffs are quite small.
But I know that's not considered the right way.


(I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)


?- Jay

 		 	   		  

From dragisha at m3w.org  Thu May 20 14:24:32 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 20 May 2010 14:24:32 +0200
Subject: [M3devel] ***SPAM*** RE:  Linux/ARM? Android?
In-Reply-To: <COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
References: <1274350133.8902.0.camel@localhost>
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
Message-ID: <1274358272.8902.2.camel@localhost>

I'll have a HTC Tattoo in a week or so. No problems then for anything.

It does not support pthread_cancel, as far as I know for now. And I
don't think we need it. Nor glibc - it's lib is bionic (didn't check it
yet).

On Thu, 2010-05-20 at 11:47 +0000, Jay K wrote:
> Status is roughly nowhere.
> Chances are not bad though.
> There is very little work to do when the system supports posix and gcc supports the system, and that describes a lot of systems.
>   Try this: cd scripts/python && ./boot1.py ARM_LINUX 
> 
> 
> Give me ssh access to a device?
>  Or maybe there is emulator?
> 
> 
> I've had a PogoPlug (Linux/ARM) for over a year, haven't touched it.
> And some I think Linux/ARM LaCie network drive also.
> 
> 
>  - Jay
> 
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: m3devel at elegosoft.com
> > Date: Thu, 20 May 2010 12:08:53 +0200
> > Subject: [M3devel] Linux/ARM? Android?
> >
> > As per subject... What is status of Linux/ARM port of Modula-3 and
> > chances for Android port?
> > --
> > Dragi?a Duri? 
> >
>  		 	   		  

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



From hosking at cs.purdue.edu  Thu May 20 15:10:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 09:10:03 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>
Message-ID: <76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>

Unfortunately, it has never been as easy as import release, merge to head.  Usually there are many differences that need to be resolved by hand.  But, that is how it should be done.

And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.

As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.

On 20 May 2010, at 07:50, Jay K wrote:

> 
> Tony, what is involved in upgrading to gcc 4.5.0?
> 
> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
> 
> Merge it to the "gcc" branch?
> 
> And then to head?
> 
> 
> 
> 
> I mean, you know..there are all the directions out there for managing
> external trees, but I think the main missing detail is what
> branches/tag names to use to match previous history, and it isn't
> immediately clear to me..from, um, reading the history (which imho is
> yet another indictment of CVS -- I can't figure out what happened).
> 
> 
> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
> But I haven't ever updated it.
> e.g. cvsup.
> 
> 
> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
> The diffs are quite small.
> But I know that's not considered the right way.
> 
> 
> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
> 
> 
>  - Jay
> 
> 		 	   		  



From jay.krell at cornell.edu  Thu May 20 15:12:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 13:12:20 +0000
Subject: [M3devel] ***SPAM*** RE:  Linux/ARM? Android?
In-Reply-To: <1274358272.8902.2.camel@localhost>
References: <1274350133.8902.0.camel@localhost>,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	<1274358272.8902.2.camel@localhost>
Message-ID: <COL101-W48D5715499DCC521AABCB1E6E30@phx.gbl>


If you can provide ssh access to it and a "native" C development environment, I'll have a go at it.
By "native" C development, I mean "official", not necessarily "hosted on the target machine".
If the C development environment is easily acquired, I can do that part. It probably is.
There's a possibility, possibility, we should have separate ARM_LINUX and ARM_ANROID or or ARM_GNU_LINUX or ARM_BIONIC_LINUX or ARM_LINUX_ANDROID or ARM_LINUX_GOOGLE or ARM_GOOGLE or ARM_LINUX_GOOGLE or ARM_GOOGLE_LINUX or ARM_OHSA_LINUX ("open handset aliance?") or such.


In particular, if there jmpbuf sizes are different, then we should.
The "Modula-3 compiler" cares only about: endian, word size, jmpbuf size, basically that's it.
?Alignment too, but they are all the same.
?"Code alignment" too, some of each, for the closure stuff.


If they aren't binary compatible, then we probably should -- just to propagate it out to the naming of packages really.


There is "something" nagging to get out that isn't a "target" or? "platform" but something like a "configuration".
?For example, SOLsun and SOLgnu are the same, except for which C compiler they use to compiler a few files, and for the C-compiler-as-linker-driver.
? They have the same jumpbuf, the same stack walker, they end up with the same #ifs in the C code, at least wrt #if __sun, not #if __GNUC__.


Basically it seems that "platform" = "kernel" + "C library" + processor + "sometimes C compiler/linker" + "Windowing system" + "GUI library" + "file i/o library"
But many of them correlate very very strongly.
"C library" varies -- uclibc, dietlibc, glibc, eglibc, bionic.
file i/o library = posix or win32
threads = pthreads or posix user threads perhaps or win32
?? (ie: we should have separate I386_LINUX_USERTHREADS?)


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 20 May 2010 14:24:32 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ***SPAM*** RE: Linux/ARM? Android?
>
> I'll have a HTC Tattoo in a week or so. No problems then for anything.
>
> It does not support pthread_cancel, as far as I know for now. And I
> don't think we need it. Nor glibc - it's lib is bionic (didn't check it
> yet).
>
> On Thu, 2010-05-20 at 11:47 +0000, Jay K wrote:
>> Status is roughly nowhere.
>> Chances are not bad though.
>> There is very little work to do when the system supports posix and gcc supports the system, and that describes a lot of systems.
>> Try this: cd scripts/python && ./boot1.py ARM_LINUX
>>
>>
>> Give me ssh access to a device?
>> Or maybe there is emulator?
>>
>>
>> I've had a PogoPlug (Linux/ARM) for over a year, haven't touched it.
>> And some I think Linux/ARM LaCie network drive also.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: dragisha at m3w.org
>>> To: m3devel at elegosoft.com
>>> Date: Thu, 20 May 2010 12:08:53 +0200
>>> Subject: [M3devel] Linux/ARM? Android?
>>>
>>> As per subject... What is status of Linux/ARM port of Modula-3 and
>>> chances for Android port?
>>> --
>>> Dragi?a Duri?
>>>
>>
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 15:21:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 13:21:09 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>
Message-ID: <COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>


eh, ok, I'll try that then.


Have you noticed what I did for OpenBSD?
Perhaps easier to just commit those diffs?
In order to facilitate merging?
Tedious either way of course.


What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
?? OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
Largely they aren't relevant, like to c-*.c.
Largely they are trivial. Just configure/makefile snippets.
Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
We apply them during our build, in m3makefile.


Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
And commit with minimal testing instead of a big matrix.


But it bloats the source tree a lot.


I'd also like to somehow reduce how often gmp and mpfr are built.
They are a huge fraction of the time.
And 4.5.0 adds another similar library, mpc.
? "c" for complex numbers..more stuff we don't use...


It seems our main changes are:
? introducing of static chain for nested procedures
? Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
? Or Pascal? I mean..do we have to add our own?

? small hacks to inhibit optimization 


? the little makefile machinery 


Also, have you noticed that 4.5.0 has a "plugin" interface?
Perhaps we can just use that, and just distribute a small .so file.
At least once 4.5.0 is in wide use.


?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 09:10:03 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>
> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>
> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>
> On 20 May 2010, at 07:50, Jay K wrote:
>
>>
>> Tony, what is involved in upgrading to gcc 4.5.0?
>>
>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>
>> Merge it to the "gcc" branch?
>>
>> And then to head?
>>
>>
>>
>>
>> I mean, you know..there are all the directions out there for managing
>> external trees, but I think the main missing detail is what
>> branches/tag names to use to match previous history, and it isn't
>> immediately clear to me..from, um, reading the history (which imho is
>> yet another indictment of CVS -- I can't figure out what happened).
>>
>>
>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>> But I haven't ever updated it.
>> e.g. cvsup.
>>
>>
>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>> The diffs are quite small.
>> But I know that's not considered the right way.
>>
>>
>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>
>>
>> - Jay
>>
>>
>
 		 	   		  

From mika at async.async.caltech.edu  Thu May 20 15:44:37 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 20 May 2010 06:44:37 -0700
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl> 
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>
Message-ID: <20100520134437.D15551A2094@async.async.caltech.edu>


I would be a bit careful here.  Presumably there are a lot of subtypes
of Random.T out there that override methods in various ways...  Layering
longint on top of multiple calls to integer (rather than the other way
around) seems like the safe approach to getting things working.

   Mika

Jay K writes:
>
>In libm3 there is random number generation.
>In libm3 that is code that wants 8 random bytes.
>=A0 If integer is 4 bytes=2C it calls random.integer() twice=2C else if it =
>is 8=2C once.
>
>It seems natural that we should provide random.longint()?
>
>And then the other code can just use it?
>
>Someone can look into the random number generator and
>=A0- make sure it is actually "correct" for 64bit integer?
>=A0- and if so=2C change the lowest level to use LONGINT
>=A0=A0 and layer integer over it? -- not sure how=2C presumably
>=A0=A0 taking only the lower 32bits loses too much randomness?
>
>
>This is what I get for looking into why we are ever asked to extract 0 bits=
>..
>
>"Everywhere I look=2C I see bugs." (topic of a separate mail)
>
>=A0- Jay
>
> 		 	   		  =


From hosking at cs.purdue.edu  Thu May 20 15:54:14 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 09:54:14 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>
Message-ID: <2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>



On 20 May 2010, at 09:21, Jay K wrote:

> 
> eh, ok, I'll try that then.
> 
> 
> Have you noticed what I did for OpenBSD?
> Perhaps easier to just commit those diffs?
> In order to facilitate merging?
> Tedious either way of course.
> 
> 
> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>    OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
> Largely they aren't relevant, like to c-*.c.
> Largely they are trivial. Just configure/makefile snippets.
> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
> We apply them during our build, in m3makefile.
> 
> 
> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
> And commit with minimal testing instead of a big matrix.
> 
> 
> But it bloats the source tree a lot.
> 
> 
> I'd also like to somehow reduce how often gmp and mpfr are built.
> They are a huge fraction of the time.
> And 4.5.0 adds another similar library, mpc.
>   "c" for complex numbers..more stuff we don't use...
> 
> 
> It seems our main changes are:
>   introducing of static chain for nested procedures
>   Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>   Or Pascal? I mean..do we have to add our own?

Yes, we need the support for extracting the static chain for passing with procedure arguments.  Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain).  i.e., they are "static" closures.

>   small hacks to inhibit optimisation

It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.

>   the little makefile machinery 
> 
> 
> Also, have you noticed that 4.5.0 has a "plugin" interface?

Yes, I'd heard about that.

> Perhaps we can just use that, and just distribute a small .so file.

That would be *very* cool.

> At least once 4.5.0 is in wide use.

Right.

> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 20 May 2010 09:10:03 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>> 
>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>> 
>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>> 
>> On 20 May 2010, at 07:50, Jay K wrote:
>> 
>>> 
>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>> 
>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>> 
>>> Merge it to the "gcc" branch?
>>> 
>>> And then to head?
>>> 
>>> 
>>> 
>>> 
>>> I mean, you know..there are all the directions out there for managing
>>> external trees, but I think the main missing detail is what
>>> branches/tag names to use to match previous history, and it isn't
>>> immediately clear to me..from, um, reading the history (which imho is
>>> yet another indictment of CVS -- I can't figure out what happened).
>>> 
>>> 
>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>> But I haven't ever updated it.
>>> e.g. cvsup.
>>> 
>>> 
>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>> The diffs are quite small.
>>> But I know that's not considered the right way.
>>> 
>>> 
>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Thu May 20 16:01:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 14:01:09 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
Message-ID: <COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>


What I meant regarding "static chain" was more like "does gcc already have support that we can use".
Don't any of the other languages need it already?
Ada? Pascal? Maybe the nested C function support?

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 09:54:14 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
>
>
> On 20 May 2010, at 09:21, Jay K wrote:
>
>>
>> eh, ok, I'll try that then.
>>
>>
>> Have you noticed what I did for OpenBSD?
>> Perhaps easier to just commit those diffs?
>> In order to facilitate merging?
>> Tedious either way of course.
>>
>>
>> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>> OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
>> Largely they aren't relevant, like to c-*.c.
>> Largely they are trivial. Just configure/makefile snippets.
>> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
>> We apply them during our build, in m3makefile.
>>
>>
>> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
>> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
>> And commit with minimal testing instead of a big matrix.
>>
>>
>> But it bloats the source tree a lot.
>>
>>
>> I'd also like to somehow reduce how often gmp and mpfr are built.
>> They are a huge fraction of the time.
>> And 4.5.0 adds another similar library, mpc.
>> "c" for complex numbers..more stuff we don't use...
>>
>>
>> It seems our main changes are:
>> introducing of static chain for nested procedures
>> Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>> Or Pascal? I mean..do we have to add our own?
>
> Yes, we need the support for extracting the static chain for passing with procedure arguments. Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain). i.e., they are "static" closures.
>
>> small hacks to inhibit optimisation
>
> It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.
>
>> the little makefile machinery
>>
>>
>> Also, have you noticed that 4.5.0 has a "plugin" interface?
>
> Yes, I'd heard about that.
>
>> Perhaps we can just use that, and just distribute a small .so file.
>
> That would be *very* cool.
>
>> At least once 4.5.0 is in wide use.
>
> Right.
>
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 20 May 2010 09:10:03 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>>>
>>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>>>
>>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>>>
>>> On 20 May 2010, at 07:50, Jay K wrote:
>>>
>>>>
>>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>>>
>>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>>>
>>>> Merge it to the "gcc" branch?
>>>>
>>>> And then to head?
>>>>
>>>>
>>>>
>>>>
>>>> I mean, you know..there are all the directions out there for managing
>>>> external trees, but I think the main missing detail is what
>>>> branches/tag names to use to match previous history, and it isn't
>>>> immediately clear to me..from, um, reading the history (which imho is
>>>> yet another indictment of CVS -- I can't figure out what happened).
>>>>
>>>>
>>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>>> But I haven't ever updated it.
>>>> e.g. cvsup.
>>>>
>>>>
>>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>>> The diffs are quite small.
>>>> But I know that's not considered the right way.
>>>>
>>>>
>>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 16:04:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 14:04:45 +0000
Subject: [M3devel] random.longint()?
In-Reply-To: <20100520134437.D15551A2094@async.async.caltech.edu>
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>,
	<20100520134437.D15551A2094@async.async.caltech.edu>
Message-ID: <COL101-W6248BB81D2C8DF3DF0D94AE6E30@phx.gbl>


I'm just going to leave it alone.
There's already code that checks BITSIZE(INTEGER) and makes one or two calls accordingly.


More interesting probably..but again probably nothing from me..is using modern OS
sources of randomness, entropy, random numbers.


http://www.opengroup.org/onlinepubs/007908799/xsh/drand48.html
http://en.wikipedia.org/wiki/CryptGenRandom


You know..sometimes underlying system doesn't offer much and you do it yourself.
Sometimes the underlying systems catch up..


?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] random.longint()?
> Date: Thu, 20 May 2010 06:44:37 -0700
> From: mika at async.async.caltech.edu
>
>
> I would be a bit careful here. Presumably there are a lot of subtypes
> of Random.T out there that override methods in various ways... Layering
> longint on top of multiple calls to integer (rather than the other way
> around) seems like the safe approach to getting things working.
>
> Mika
>
> Jay K writes:
>>
>>In libm3 there is random number generation.
>>In libm3 that is code that wants 8 random bytes.
>>=A0 If integer is 4 bytes=2C it calls random.integer() twice=2C else if it =
>>is 8=2C once.
>>
>>It seems natural that we should provide random.longint()?
>>
>>And then the other code can just use it?
>>
>>Someone can look into the random number generator and
>>=A0- make sure it is actually "correct" for 64bit integer?
>>=A0- and if so=2C change the lowest level to use LONGINT
>>=A0=A0 and layer integer over it? -- not sure how=2C presumably
>>=A0=A0 taking only the lower 32bits loses too much randomness?
>>
>>
>>This is what I get for looking into why we are ever asked to extract 0 bits=
>>..
>>
>>"Everywhere I look=2C I see bugs." (topic of a separate mail)
>>
>>=A0- Jay
>>
>> =
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 15:59:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 13:59:53 +0000
Subject: [M3devel] limiting .so exports
Message-ID: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>


limiting .so exports
?(and direct binding to symbols in same .so)


FYI:


No clear question here, just a heads up regarding stuff that might be coming.



I'm working on limiting .so exports to only "what they should be".


In particular, given:

INTERFACE Foo;

PROCEDURE Bar();

END Foo.

MODULE Foo;

PROCEDURE F() = BEGIN ... END F;

PROCEDURE Bar() = BEGIN F(); END Bar;

END Foo.


Foo__F should not exported.
Foo__Bar should be.


Today they both would be.
Or at least in the recent past.
?I already made a change in parse.c to reduce things.


However at that level I don't believe we have the needed information.
? (needs investigation)


What I have is that in MxOut.m3, I write out all the symbols in
import_def_syms for modules.
Plus the _M3 and _I3 symbols.


That is most of the work.
However there are missing or non-ideal parts.


In the config files I then transform the list into the format
required by the compiler/linker. I was doing the transform in MxOut.m3
but it was getting to be "too much" work.


You also need to export anything marked <* EXTERNAL *> in interfaces.
I can get that list, however I have been using the "trick" of not
always implementing all EXTERNALs.
Sometimes the C implementation has #ifdefs around it.
So that becomes difficult.


gcc has __attribute__ and #pragma GCC visibility to control things
also, but this seems to conflict with giving a list in a file to
the compiler/linker.


What I have currently is that after compiling any C file, I run
nm on it to get its symbols.


I combine the nm output with the MxOut.m3 output.


Unfortunately that exports more of the C code than intended.
But code that always was exported -- like all of ThreadPThread.c.


As well something I haven't fixed yet is that lowercase interface
contents should not be exported, only capital Interface.


The list would be presented with
? GNU ld: --version-script
? Sun ld: -M for mapfile
? Mac ld: --export-symbol-list


Sun ld and GNU ld accept roughly the same input.


I'm not sure how these two mechanisms compare.
It could be that it is better to use source/parse.c-level "visibility"
and not present the lists to the linker.
In particular that allows for not exporting more of the C.


I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.


The "list" approach should probably at least be used on NT/Cygwin.
Currently we export everything by mklib enumerating the symbols.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Thu May 20 16:50:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 10:50:42 -0400
Subject: [M3devel] limiting .so exports
In-Reply-To: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>
References: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>
Message-ID: <4940E887-0077-434D-A63E-88D76D6E76DA@cs.purdue.edu>

Can we not just push more information through to the back-ends for import_global/import_procedure?  The front-end would need to know where it found the import (in the local package or in another imported package) but all that information would be derivable from m3linker wouldn't it?




On 20 May 2010, at 09:59, Jay K wrote:

> 
> limiting .so exports
>  (and direct binding to symbols in same .so)
> 
> 
> FYI:
> 
> 
> No clear question here, just a heads up regarding stuff that might be coming.
> 
> 
> 
> I'm working on limiting .so exports to only "what they should be".
> 
> 
> In particular, given:
> 
> INTERFACE Foo;
> 
> PROCEDURE Bar();
> 
> END Foo.
> 
> MODULE Foo;
> 
> PROCEDURE F() = BEGIN ... END F;
> 
> PROCEDURE Bar() = BEGIN F(); END Bar;
> 
> END Foo.
> 
> 
> Foo__F should not exported.
> Foo__Bar should be.
> 
> 
> Today they both would be.
> Or at least in the recent past.
>  I already made a change in parse.c to reduce things.
> 
> 
> However at that level I don't believe we have the needed information.
>   (needs investigation)
> 
> 
> What I have is that in MxOut.m3, I write out all the symbols in
> import_def_syms for modules.
> Plus the _M3 and _I3 symbols.
> 
> 
> That is most of the work.
> However there are missing or non-ideal parts.
> 
> 
> In the config files I then transform the list into the format
> required by the compiler/linker. I was doing the transform in MxOut.m3
> but it was getting to be "too much" work.
> 
> 
> You also need to export anything marked <* EXTERNAL *> in interfaces.
> I can get that list, however I have been using the "trick" of not
> always implementing all EXTERNALs.
> Sometimes the C implementation has #ifdefs around it.
> So that becomes difficult.
> 
> 
> gcc has __attribute__ and #pragma GCC visibility to control things
> also, but this seems to conflict with giving a list in a file to
> the compiler/linker.
> 
> 
> What I have currently is that after compiling any C file, I run
> nm on it to get its symbols.
> 
> 
> I combine the nm output with the MxOut.m3 output.
> 
> 
> Unfortunately that exports more of the C code than intended.
> But code that always was exported -- like all of ThreadPThread.c.
> 
> 
> As well something I haven't fixed yet is that lowercase interface
> contents should not be exported, only capital Interface.
> 
> 
> The list would be presented with
>   GNU ld: --version-script
>   Sun ld: -M for mapfile
>   Mac ld: --export-symbol-list
> 
> 
> Sun ld and GNU ld accept roughly the same input.
> 
> 
> I'm not sure how these two mechanisms compare.
> It could be that it is better to use source/parse.c-level "visibility"
> and not present the lists to the linker.
> In particular that allows for not exporting more of the C.
> 
> 
> I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.
> 
> 
> The "list" approach should probably at least be used on NT/Cygwin.
> Currently we export everything by mklib enumerating the symbols.
> 
> 
>  - Jay
> 		 	   		  



From hosking at cs.purdue.edu  Thu May 20 16:52:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 10:52:03 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
Message-ID: <DAB881D4-AB78-4C8D-842A-3A9448AA5B6A@cs.purdue.edu>

Yes, we do make use of some of gcc's static chain machinery.  We just avoid the need for the trampolines that gcc uses because we need a reified static chain that is otherwise computed in the trampoline on the way to calling a nested procedure.

On 20 May 2010, at 10:01, Jay K wrote:

> 
> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
> Don't any of the other languages need it already?
> Ada? Pascal? Maybe the nested C function support?
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 20 May 2010 09:54:14 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> 
>> 
>> On 20 May 2010, at 09:21, Jay K wrote:
>> 
>>> 
>>> eh, ok, I'll try that then.
>>> 
>>> 
>>> Have you noticed what I did for OpenBSD?
>>> Perhaps easier to just commit those diffs?
>>> In order to facilitate merging?
>>> Tedious either way of course.
>>> 
>>> 
>>> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>>> OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
>>> Largely they aren't relevant, like to c-*.c.
>>> Largely they are trivial. Just configure/makefile snippets.
>>> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
>>> We apply them during our build, in m3makefile.
>>> 
>>> 
>>> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
>>> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
>>> And commit with minimal testing instead of a big matrix.
>>> 
>>> 
>>> But it bloats the source tree a lot.
>>> 
>>> 
>>> I'd also like to somehow reduce how often gmp and mpfr are built.
>>> They are a huge fraction of the time.
>>> And 4.5.0 adds another similar library, mpc.
>>> "c" for complex numbers..more stuff we don't use...
>>> 
>>> 
>>> It seems our main changes are:
>>> introducing of static chain for nested procedures
>>> Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>>> Or Pascal? I mean..do we have to add our own?
>> 
>> Yes, we need the support for extracting the static chain for passing with procedure arguments. Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain). i.e., they are "static" closures.
>> 
>>> small hacks to inhibit optimisation
>> 
>> It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.
>> 
>>> the little makefile machinery
>>> 
>>> 
>>> Also, have you noticed that 4.5.0 has a "plugin" interface?
>> 
>> Yes, I'd heard about that.
>> 
>>> Perhaps we can just use that, and just distribute a small .so file.
>> 
>> That would be *very* cool.
>> 
>>> At least once 4.5.0 is in wide use.
>> 
>> Right.
>> 
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Thu, 20 May 2010 09:10:03 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>> 
>>>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>>>> 
>>>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>>>> 
>>>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>>>> 
>>>> On 20 May 2010, at 07:50, Jay K wrote:
>>>> 
>>>>> 
>>>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>>>> 
>>>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>>>> 
>>>>> Merge it to the "gcc" branch?
>>>>> 
>>>>> And then to head?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> I mean, you know..there are all the directions out there for managing
>>>>> external trees, but I think the main missing detail is what
>>>>> branches/tag names to use to match previous history, and it isn't
>>>>> immediately clear to me..from, um, reading the history (which imho is
>>>>> yet another indictment of CVS -- I can't figure out what happened).
>>>>> 
>>>>> 
>>>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>>>> But I haven't ever updated it.
>>>>> e.g. cvsup.
>>>>> 
>>>>> 
>>>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>>>> The diffs are quite small.
>>>>> But I know that's not considered the right way.
>>>>> 
>>>>> 
>>>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Thu May 20 17:28:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 15:28:19 +0000
Subject: [M3devel] limiting .so exports
In-Reply-To: <4940E887-0077-434D-A63E-88D76D6E76DA@cs.purdue.edu>
References: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>,
	<4940E887-0077-434D-A63E-88D76D6E76DA@cs.purdue.edu>
Message-ID: <COL101-W51B9331953E9EB9AA6B2FAE6E30@phx.gbl>


I'm not sure of much right now, I have to rest and come back.

I'm quite dissatisifed with gcc/gnuld currently.
I don't want to tell the compiler anything really.
I want all function calls to always use x86 0xE8 opcode which is a direct pc-relative call, and then have the linker generate small stubs for anything that ends up external.
? That is how NT/x86 works and it is reasonably simple and efficient. Cross-.so calls would be slightly penalized, since if you did tell the compiler about them, it might inline the stub at the call. (The NT/x86 stubs are just one jmp instruction, but they aren't necessarily position-independent).
And I want to mostly give the linker a list of exports, plus maybe a few source annotations for exports.
I'd like source annotations and the lists to be additive. Maybe the "local: *" in my current code is wrong.


There seem to be so many features/switches, and it is hard/impossible to extract something simple, understandable, efficient.
I have trouble getting a mental model of how ld/ld.so work on most platforms.
The model on NT seems simple..

Attached is what I have so far..but I'm not entirely happy with it..
It is disabled in its current form.

It would also be nice if visibility(protected) worked.
It does sometimes, for calls, but not for taking the address of a function.

Anyway...
?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 10:50:42 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] limiting .so exports
>
> Can we not just push more information through to the back-ends for import_global/import_procedure? The front-end would need to know where it found the import (in the local package or in another imported package) but all that information would be derivable from m3linker wouldn't it?
>
>
>
>
> On 20 May 2010, at 09:59, Jay K wrote:
>
>>
>> limiting .so exports
>> (and direct binding to symbols in same .so)
>>
>>
>> FYI:
>>
>>
>> No clear question here, just a heads up regarding stuff that might be coming.
>>
>>
>>
>> I'm working on limiting .so exports to only "what they should be".
>>
>>
>> In particular, given:
>>
>> INTERFACE Foo;
>>
>> PROCEDURE Bar();
>>
>> END Foo.
>>
>> MODULE Foo;
>>
>> PROCEDURE F() = BEGIN ... END F;
>>
>> PROCEDURE Bar() = BEGIN F(); END Bar;
>>
>> END Foo.
>>
>>
>> Foo__F should not exported.
>> Foo__Bar should be.
>>
>>
>> Today they both would be.
>> Or at least in the recent past.
>> I already made a change in parse.c to reduce things.
>>
>>
>> However at that level I don't believe we have the needed information.
>> (needs investigation)
>>
>>
>> What I have is that in MxOut.m3, I write out all the symbols in
>> import_def_syms for modules.
>> Plus the _M3 and _I3 symbols.
>>
>>
>> That is most of the work.
>> However there are missing or non-ideal parts.
>>
>>
>> In the config files I then transform the list into the format
>> required by the compiler/linker. I was doing the transform in MxOut.m3
>> but it was getting to be "too much" work.
>>
>>
>> You also need to export anything marked <* EXTERNAL *> in interfaces.
>> I can get that list, however I have been using the "trick" of not
>> always implementing all EXTERNALs.
>> Sometimes the C implementation has #ifdefs around it.
>> So that becomes difficult.
>>
>>
>> gcc has __attribute__ and #pragma GCC visibility to control things
>> also, but this seems to conflict with giving a list in a file to
>> the compiler/linker.
>>
>>
>> What I have currently is that after compiling any C file, I run
>> nm on it to get its symbols.
>>
>>
>> I combine the nm output with the MxOut.m3 output.
>>
>>
>> Unfortunately that exports more of the C code than intended.
>> But code that always was exported -- like all of ThreadPThread.c.
>>
>>
>> As well something I haven't fixed yet is that lowercase interface
>> contents should not be exported, only capital Interface.
>>
>>
>> The list would be presented with
>> GNU ld: --version-script
>> Sun ld: -M for mapfile
>> Mac ld: --export-symbol-list
>>
>>
>> Sun ld and GNU ld accept roughly the same input.
>>
>>
>> I'm not sure how these two mechanisms compare.
>> It could be that it is better to use source/parse.c-level "visibility"
>> and not present the lists to the linker.
>> In particular that allows for not exporting more of the C.
>>
>>
>> I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.
>>
>>
>> The "list" approach should probably at least be used on NT/Cygwin.
>> Currently we export everything by mklib enumerating the symbols.
>>
>>
>> - Jay
>>
>
 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exports.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100520/f98ad3ee/attachment-0001.txt>

From rodney_bates at lcwb.coop  Thu May 20 19:12:00 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 20 May 2010 12:12:00 -0500
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
Message-ID: <4BF56D60.2000403@lcwb.coop>

gcc even extends C with nested functions, and the support is there for that.  We use it too.

Beware:  The runtime model is, IMO, bizarre.  Definitely counterintuitive and unlike anything
you will ever see elsewhere.  There are two static links.  One is used for the first step
in following a static chain and points to the expected place in the target frame.  The other
is used of subsequent steps in chain-following, and points to somewhere inside the target
frame that is dependent on the target procedure.  It's the beginning of a subrecord where
all the nonlocally-referenced variables are collected.  The second static link is also
located in there.  All the nonlocally-referenced variables and parameters are duplicated
in there too.

I'm not sure I remembered these details exactly right.  Maybe both links point to the
subrecord, but one is located at a traditional procedure-independent, fixed location
in the frame, while the second is located in the subrecord.  Also, sometimes the first
static link value is kept in a register and never stored.

What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
scheme that, I believe came from interaction between nested procedures and inlining them.

But it's at the cost of what I would call an insanely complicated _runtime_ scheme.

It undermined m3gdb's handling of static links, and I don't think it's possible to fix
with the current design of emitting debug info very early.  The locations and target
offsets of these things aren't know until later, and m3gdb really needs to know them.


Jay K wrote:
> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
> Don't any of the other languages need it already?
> Ada? Pascal? Maybe the nested C function support?
> 
>  - Jay
> 


From jay.krell at cornell.edu  Fri May 21 03:43:08 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 01:43:08 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <4BF56D60.2000403@lcwb.coop>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>,
	, , <76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	<4BF56D60.2000403@lcwb.coop>
Message-ID: <COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>


Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
 
 
The static link is an extra parameter.
And, as such, also an extra local variable.
You only need one.
Each nesting level would follow another chain.
Or you can pass each nesting level as an extra parameter.
Or you can optimize and pass locals/parameters separately.
But there is an obvious straightforward non-optimized form. ?
 
 
Here, I worked it through:
 
 
 
Why doesn't it just look something like this:
 
 
nested:
 
void F1(int a, int b)
{
  int c = a + b;
 
  int f2()
  {
    int d = a + b;
 
    int f3()
    {
       return d + a + c;
    }
 
    return a + c + f3();
  }
 
  return f2();
}
 
not nested:
 

typedef struct {
  /* locals */
  int d;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
  f1_frame_t* f1;
} f2_frame_t;
 

typedef struct {
  /* locals */
  int c;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
  int a;
  int b;
} f1_frame_t;
 
 
int f3(f2_frame_t* f2)
{
    return f2->d + f2->f1->a + f2->f1->c;
}
 

int f2(f1_frame_t* f1)
{
  int d = f1->a + f1->b;
  return f1->a + f1->c + f3((f2_frame_t*)&d);
}
 

int F1(int a, int b)
{
  int c = a + b;
  return f2((f1_frame_t*)&c);
}

 
or, alernatively, almost the same, pass each chain as another parameter:
 

typedef struct {
  /* locals */
  int d;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
} f2_frame_t;
 

typedef struct {
  /* locals */
  int c;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
  int a;
  int b;
} f1_frame_t;
 
 
int f3(f2_frame_t* f2, f1_frame_t* f1)
{
    return f2->d + f1->a + f1->c;
}
 
 

int f2(f1_frame_t* f1)
{
  int d = f1->a + f1->b;
  return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
}
 

int F1(int a, int b)
{
  int c = a + b;
  return f2((f1_frame_t*)&c);
}
 
 
This should be easily adapted to any function call convention/sequence.
e.g. even if parameters are passed in registers.
 
 
And for that matter, why don't we just transform it to be like this?
  With the goal of reducing/eliminating gcc patches?
 
 
Am I missing something?
 

This form doesn't work?
 

Isn't reasonably simple?
 

Granted it might not be optimal. But it depends.
  You know, you can copy in the local/parameter values, but then you have
   to copy them out too. You can do analysis to show they aren't changed,
   in which case no need to copy them out.
  Similarly you can pass the parameters as separate parameters, by address
   if they are ever changed.

 
A portable transform couldn't depend on adjacency of locals and parameters.
It would have to either copy the parameters into the frame_t, or their addresses.
 
 
A portable form couldn't get the frame by taking the address of a "individual" local.
 
 
Here is portable form:
 
 
typedef struct {
  int d;
  f1_frame_t* f1;
} f2_frame_t;
 
typedef struct {
  int a;
  int b;
  int c;
} f1_frame_t;
 

int f3(f2_frame_t* f2)
{
    return f2->d + f2->f1->a + f2->f1->c;
}
 
int f2(f1_frame_t* f1)
{
  f2_frame_t f;
  f.f1 = f1;
  f.d = f1->a + f1->b;
  return f1->a + f1->c + f3(&f);
}
 
 
int F1(int a, int b)
{
  f1_frame_t f;
  f.a = a;
  f.b = b;
  f.c = a + b;
  return f2(&f);
}
 
 
or:
 
 
typedef struct {
  int d;
} f2_frame_t;
 
 
typedef struct {
  int a;
  int b;
  int c;
} f1_frame_t;
 
 
int f3(f2_frame_t* f2, f1_frame_t* f1)
{
    return f2->d + f1->a + f1->c;
}
 
 
int f2(f1_frame_t* f1)
{
  f2_frame_t f;
  f.d = f1->a + f1->b;
  return f1->a + f1->c + f3(&f, f1);
}

 
int F1(int a, int b)
{
  f1_frame_t f;
  f.a = a;
  f.b = b;
  f.c = a + b;
  return f2(&f);
}

 
 
 
 - Jay



----------------------------------------
> Date: Thu, 20 May 2010 12:12:00 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> gcc even extends C with nested functions, and the support is there for that. We use it too.
>
> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
> you will ever see elsewhere. There are two static links. One is used for the first step
> in following a static chain and points to the expected place in the target frame. The other
> is used of subsequent steps in chain-following, and points to somewhere inside the target
> frame that is dependent on the target procedure. It's the beginning of a subrecord where
> all the nonlocally-referenced variables are collected. The second static link is also
> located in there. All the nonlocally-referenced variables and parameters are duplicated
> in there too.
>
> I'm not sure I remembered these details exactly right. Maybe both links point to the
> subrecord, but one is located at a traditional procedure-independent, fixed location
> in the frame, while the second is located in the subrecord. Also, sometimes the first
> static link value is kept in a register and never stored.
>
> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
> scheme that, I believe came from interaction between nested procedures and inlining them.
>
> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>
> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
> with the current design of emitting debug info very early. The locations and target
> offsets of these things aren't know until later, and m3gdb really needs to know them.
>
>
> Jay K wrote:
>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>> Don't any of the other languages need it already?
>> Ada? Pascal? Maybe the nested C function support?
>>
>> - Jay
>> 		 	   		  

From hosking at cs.purdue.edu  Fri May 21 04:22:46 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 22:22:46 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	<4BF56D60.2000403@lcwb.coop>
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
Message-ID: <AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>

That is the standard formulation, but different architectures have different optimised forms (passing static link in a register, etc.).  In any case, gcc has its own weird way of doing things, which we mostly use, but from which we need a little extra support (hence the small amount of special tailoring).

On 20 May 2010, at 21:43, Jay K wrote:

> 
> Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
> 
> 
> The static link is an extra parameter.
> And, as such, also an extra local variable.
> You only need one.
> Each nesting level would follow another chain.
> Or you can pass each nesting level as an extra parameter.
> Or you can optimize and pass locals/parameters separately.
> But there is an obvious straightforward non-optimized form. ?
> 
> 
> Here, I worked it through:
> 
> 
> 
> Why doesn't it just look something like this:
> 
> 
> nested:
> 
> void F1(int a, int b)
> {
>  int c = a + b;
> 
>  int f2()
>  {
>    int d = a + b;
> 
>    int f3()
>    {
>       return d + a + c;
>    }
> 
>    return a + c + f3();
>  }
> 
>  return f2();
> }
> 
> not nested:
> 
> 
> typedef struct {
>  /* locals */
>  int d;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
>  f1_frame_t* f1;
> } f2_frame_t;
> 
> 
> typedef struct {
>  /* locals */
>  int c;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
>  int a;
>  int b;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2)
> {
>    return f2->d + f2->f1->a + f2->f1->c;
> }
> 
> 
> int f2(f1_frame_t* f1)
> {
>  int d = f1->a + f1->b;
>  return f1->a + f1->c + f3((f2_frame_t*)&d);
> }
> 
> 
> int F1(int a, int b)
> {
>  int c = a + b;
>  return f2((f1_frame_t*)&c);
> }
> 
> 
> or, alernatively, almost the same, pass each chain as another parameter:
> 
> 
> typedef struct {
>  /* locals */
>  int d;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
> } f2_frame_t;
> 
> 
> typedef struct {
>  /* locals */
>  int c;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
>  int a;
>  int b;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>    return f2->d + f1->a + f1->c;
> }
> 
> 
> 
> int f2(f1_frame_t* f1)
> {
>  int d = f1->a + f1->b;
>  return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
> }
> 
> 
> int F1(int a, int b)
> {
>  int c = a + b;
>  return f2((f1_frame_t*)&c);
> }
> 
> 
> This should be easily adapted to any function call convention/sequence.
> e.g. even if parameters are passed in registers.
> 
> 
> And for that matter, why don't we just transform it to be like this?
>  With the goal of reducing/eliminating gcc patches?
> 
> 
> Am I missing something?
> 
> 
> This form doesn't work?
> 
> 
> Isn't reasonably simple?
> 
> 
> Granted it might not be optimal. But it depends.
>  You know, you can copy in the local/parameter values, but then you have
>   to copy them out too. You can do analysis to show they aren't changed,
>   in which case no need to copy them out.
>  Similarly you can pass the parameters as separate parameters, by address
>   if they are ever changed.
> 
> 
> A portable transform couldn't depend on adjacency of locals and parameters.
> It would have to either copy the parameters into the frame_t, or their addresses.
> 
> 
> A portable form couldn't get the frame by taking the address of a "individual" local.
> 
> 
> Here is portable form:
> 
> 
> typedef struct {
>  int d;
>  f1_frame_t* f1;
> } f2_frame_t;
> 
> typedef struct {
>  int a;
>  int b;
>  int c;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2)
> {
>    return f2->d + f2->f1->a + f2->f1->c;
> }
> 
> int f2(f1_frame_t* f1)
> {
>  f2_frame_t f;
>  f.f1 = f1;
>  f.d = f1->a + f1->b;
>  return f1->a + f1->c + f3(&f);
> }
> 
> 
> int F1(int a, int b)
> {
>  f1_frame_t f;
>  f.a = a;
>  f.b = b;
>  f.c = a + b;
>  return f2(&f);
> }
> 
> 
> or:
> 
> 
> typedef struct {
>  int d;
> } f2_frame_t;
> 
> 
> typedef struct {
>  int a;
>  int b;
>  int c;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>    return f2->d + f1->a + f1->c;
> }
> 
> 
> int f2(f1_frame_t* f1)
> {
>  f2_frame_t f;
>  f.d = f1->a + f1->b;
>  return f1->a + f1->c + f3(&f, f1);
> }
> 
> 
> int F1(int a, int b)
> {
>  f1_frame_t f;
>  f.a = a;
>  f.b = b;
>  f.c = a + b;
>  return f2(&f);
> }
> 
> 
> 
> 
> - Jay
> 
> 
> 
> ----------------------------------------
>> Date: Thu, 20 May 2010 12:12:00 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> gcc even extends C with nested functions, and the support is there for that. We use it too.
>> 
>> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
>> you will ever see elsewhere. There are two static links. One is used for the first step
>> in following a static chain and points to the expected place in the target frame. The other
>> is used of subsequent steps in chain-following, and points to somewhere inside the target
>> frame that is dependent on the target procedure. It's the beginning of a subrecord where
>> all the nonlocally-referenced variables are collected. The second static link is also
>> located in there. All the nonlocally-referenced variables and parameters are duplicated
>> in there too.
>> 
>> I'm not sure I remembered these details exactly right. Maybe both links point to the
>> subrecord, but one is located at a traditional procedure-independent, fixed location
>> in the frame, while the second is located in the subrecord. Also, sometimes the first
>> static link value is kept in a register and never stored.
>> 
>> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
>> scheme that, I believe came from interaction between nested procedures and inlining them.
>> 
>> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>> 
>> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
>> with the current design of emitting debug info very early. The locations and target
>> offsets of these things aren't know until later, and m3gdb really needs to know them.
>> 
>> 
>> Jay K wrote:
>>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>>> Don't any of the other languages need it already?
>>> Ada? Pascal? Maybe the nested C function support?
>>> 
>>> - Jay
>>> 		 	   		  



From rcolebur at SCIRES.COM  Fri May 21 06:26:38 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 21 May 2010 00:26:38 -0400
Subject: [M3devel] m3core build failure
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>

I am getting a build error on Windows for m3core in HEAD branch:

"C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading

Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem.  Shouldn't this be "NT386" instead of "WIN32"?

Here is offending m3makefile:

C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
% Copyright (C) 1992, Digital Equipment Corporation
% All rights reserved.
% See the file COPYRIGHT for a full description.
%
% Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
%      modified on Wed Jun  9 17:25:51 PDT 1993 by harrison
%      modified on Thu May  6 12:11:46 PDT 1993 by muller
%      modified on Wed May  5 11:53:58 PDT 1993 by mjordan

include_dir ("Common")
include_dir (TARGET)
if equal(OS_TYPE, "WIN32")
  % long is 32bits even on 64bit Windows
  include("32BITS")
else
  include_dir (WORD_SIZE)
end

Regards,
Randy

________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100521/b1d89886/attachment-0001.html>

From jay.krell at cornell.edu  Fri May 21 06:44:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 04:44:25 +0000
Subject: [M3devel] m3core build failure
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>


Oops, it should be include_dir.
 
 
32BITS is deliberate -- 32bits has a 32bit long, 64bits has a 64bit long, all Win32 platforms, 32bit or 64bit, have a 32bit long.
 
 
We really should just not have long anywhere, but that might be difficult to achieve.
   The often purported portable meaning of "long", that is a pointer-sized, is false.
The pointer sized integers are INTEGER and Word.T, not "long".
 
 
 
 - Jay

________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Fri, 21 May 2010 00:26:38 -0400
> Subject: [M3devel] m3core build failure
>
>
>
>
>
>
>
>
>
>
>
>
> I am getting a build error on Windows for m3core in HEAD branch:
>
>
>
>
>
> "C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
>
>
> unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading
>
>
>
>
>
> Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem. Shouldn?t this be ?NT386? instead of ?WIN32??
>
>
>
>
>
> Here is offending m3makefile:
>
>
>
>
>
> C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
>
>
> % Copyright (C) 1992, Digital Equipment Corporation
>
>
> % All rights reserved.
>
>
> % See the file COPYRIGHT for a full description.
>
>
> %
>
>
> % Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
>
>
> % modified on Wed Jun 9 17:25:51 PDT 1993 by harrison
>
>
> % modified on Thu May 6 12:11:46 PDT 1993 by muller
>
>
> % modified on Wed May 5 11:53:58 PDT 1993 by mjordan
>
>
>
>
>
> include_dir ("Common")
>
>
> include_dir (TARGET)
>
>
> if equal(OS_TYPE, "WIN32")
>
>
> % long is 32bits even on 64bit Windows
>
>
> include("32BITS")
>
>
> else
>
>
> include_dir (WORD_SIZE)
>
>
> end
>
>
>
>
>
> Regards,
>
>
> Randy
>
>
>
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation.
> If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately
> and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>
>
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical
> data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data
> may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will
> comply with all applicable ITAR, EAR and embargo compliance requirements.
> 		 	   		  

From jay.krell at cornell.edu  Fri May 21 06:47:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 04:47:54 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	,,<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	,,<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	, , <2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, ,
	<4BF56D60.2000403@lcwb.coop>,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>
Message-ID: <COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>


Maybe we can/should transform into one of the forms I show and dispense with any gcc support?
At the cost of losing some "easy" optimization..of nested functions?
  "easy" as in, occurs even without -O2, but might occur with -O2?
 
 
I know what you mean -- NT386 passes the static link in ecx.
This is "ok" because in C++ the "this" pointer is passed in ecx.
 
 
Passing it as "just" another parameter might be less efficient, but ok?
  And really, it'd only be less efficient on one architecture -- 32bit x86.
  And maybe not all x86s -- depending on if some ABIs have a register based calling convention.
 
 
We don't need any actual ABI-compatibility with anything here, do we?
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 22:22:46 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> That is the standard formulation, but different architectures have different optimised forms (passing static link in a register, etc.). In any case, gcc has its own weird way of doing things, which we mostly use, but from which we need a little extra support (hence the small amount of special tailoring).
>
> On 20 May 2010, at 21:43, Jay K wrote:
>
>>
>> Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
>>
>>
>> The static link is an extra parameter.
>> And, as such, also an extra local variable.
>> You only need one.
>> Each nesting level would follow another chain.
>> Or you can pass each nesting level as an extra parameter.
>> Or you can optimize and pass locals/parameters separately.
>> But there is an obvious straightforward non-optimized form. ?
>>
>>
>> Here, I worked it through:
>>
>>
>>
>> Why doesn't it just look something like this:
>>
>>
>> nested:
>>
>> void F1(int a, int b)
>> {
>> int c = a + b;
>>
>> int f2()
>> {
>> int d = a + b;
>>
>> int f3()
>> {
>> return d + a + c;
>> }
>>
>> return a + c + f3();
>> }
>>
>> return f2();
>> }
>>
>> not nested:
>>
>>
>> typedef struct {
>> /* locals */
>> int d;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> f1_frame_t* f1;
>> } f2_frame_t;
>>
>>
>> typedef struct {
>> /* locals */
>> int c;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> int a;
>> int b;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2)
>> {
>> return f2->d + f2->f1->a + f2->f1->c;
>> }
>>
>>
>> int f2(f1_frame_t* f1)
>> {
>> int d = f1->a + f1->b;
>> return f1->a + f1->c + f3((f2_frame_t*)&d);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> int c = a + b;
>> return f2((f1_frame_t*)&c);
>> }
>>
>>
>> or, alernatively, almost the same, pass each chain as another parameter:
>>
>>
>> typedef struct {
>> /* locals */
>> int d;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> } f2_frame_t;
>>
>>
>> typedef struct {
>> /* locals */
>> int c;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> int a;
>> int b;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2, f1_frame_t* f1)
>> {
>> return f2->d + f1->a + f1->c;
>> }
>>
>>
>>
>> int f2(f1_frame_t* f1)
>> {
>> int d = f1->a + f1->b;
>> return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> int c = a + b;
>> return f2((f1_frame_t*)&c);
>> }
>>
>>
>> This should be easily adapted to any function call convention/sequence.
>> e.g. even if parameters are passed in registers.
>>
>>
>> And for that matter, why don't we just transform it to be like this?
>> With the goal of reducing/eliminating gcc patches?
>>
>>
>> Am I missing something?
>>
>>
>> This form doesn't work?
>>
>>
>> Isn't reasonably simple?
>>
>>
>> Granted it might not be optimal. But it depends.
>> You know, you can copy in the local/parameter values, but then you have
>> to copy them out too. You can do analysis to show they aren't changed,
>> in which case no need to copy them out.
>> Similarly you can pass the parameters as separate parameters, by address
>> if they are ever changed.
>>
>>
>> A portable transform couldn't depend on adjacency of locals and parameters.
>> It would have to either copy the parameters into the frame_t, or their addresses.
>>
>>
>> A portable form couldn't get the frame by taking the address of a "individual" local.
>>
>>
>> Here is portable form:
>>
>>
>> typedef struct {
>> int d;
>> f1_frame_t* f1;
>> } f2_frame_t;
>>
>> typedef struct {
>> int a;
>> int b;
>> int c;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2)
>> {
>> return f2->d + f2->f1->a + f2->f1->c;
>> }
>>
>> int f2(f1_frame_t* f1)
>> {
>> f2_frame_t f;
>> f.f1 = f1;
>> f.d = f1->a + f1->b;
>> return f1->a + f1->c + f3(&f);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> f1_frame_t f;
>> f.a = a;
>> f.b = b;
>> f.c = a + b;
>> return f2(&f);
>> }
>>
>>
>> or:
>>
>>
>> typedef struct {
>> int d;
>> } f2_frame_t;
>>
>>
>> typedef struct {
>> int a;
>> int b;
>> int c;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2, f1_frame_t* f1)
>> {
>> return f2->d + f1->a + f1->c;
>> }
>>
>>
>> int f2(f1_frame_t* f1)
>> {
>> f2_frame_t f;
>> f.d = f1->a + f1->b;
>> return f1->a + f1->c + f3(&f, f1);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> f1_frame_t f;
>> f.a = a;
>> f.b = b;
>> f.c = a + b;
>> return f2(&f);
>> }
>>
>>
>>
>>
>> - Jay
>>
>>
>>
>> ----------------------------------------
>>> Date: Thu, 20 May 2010 12:12:00 -0500
>>> From: rodney_bates at lcwb.coop
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>> gcc even extends C with nested functions, and the support is there for that. We use it too.
>>>
>>> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
>>> you will ever see elsewhere. There are two static links. One is used for the first step
>>> in following a static chain and points to the expected place in the target frame. The other
>>> is used of subsequent steps in chain-following, and points to somewhere inside the target
>>> frame that is dependent on the target procedure. It's the beginning of a subrecord where
>>> all the nonlocally-referenced variables are collected. The second static link is also
>>> located in there. All the nonlocally-referenced variables and parameters are duplicated
>>> in there too.
>>>
>>> I'm not sure I remembered these details exactly right. Maybe both links point to the
>>> subrecord, but one is located at a traditional procedure-independent, fixed location
>>> in the frame, while the second is located in the subrecord. Also, sometimes the first
>>> static link value is kept in a register and never stored.
>>>
>>> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
>>> scheme that, I believe came from interaction between nested procedures and inlining them.
>>>
>>> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>>>
>>> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
>>> with the current design of emitting debug info very early. The locations and target
>>> offsets of these things aren't know until later, and m3gdb really needs to know them.
>>>
>>>
>>> Jay K wrote:
>>>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>>>> Don't any of the other languages need it already?
>>>> Ada? Pascal? Maybe the nested C function support?
>>>>
>>>> - Jay
>>>>
> 		 	   		  

From rcolebur at SCIRES.COM  Fri May 21 07:00:17 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 21 May 2010 01:00:17 -0400
Subject: [M3devel] m3core build failure
In-Reply-To: <COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>
References: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C191D33D@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Thanks for the reply.

I don't think that is all that is wrong.  I changed to "include_dir", but now I am getting other errors.  For example:

new source -> compiling UnixC.c
cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
Oi -c ..\\src\\unix\\Common\\UnixC.c
UnixC.c
..\\src\\unix\\Common\\UnixC.c(95) : error C2375: 'Unix__open' : redefinition; d
ifferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(329) : see declaration of 'Un
ix__open'
..\\src\\unix\\Common\\UnixC.c(96) : error C2375: 'Unix__umask' : redefinition;
different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(337) : see declaration of 'Un
ix__umask'
..\\src\\unix\\Common\\UnixC.c(97) : error C2375: 'Unix__chmod' : redefinition;
different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(357) : see declaration of 'Un
ix__chmod'
..\\src\\unix\\Common\\UnixC.c(98) : error C2375: 'Unix__creat' : redefinition;
different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(361) : see declaration of 'Un
ix__creat'
..\\src\\unix\\Common\\UnixC.c(99) : error C2375: 'Unix__dup' : redefinition; di
fferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(362) : see declaration of 'Un
ix__dup'
  compile_c => 2
C compiler failed compiling: ..\src\unix\Common\UnixC.c
new source -> compiling Uin.c
cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
Oi -c ..\\src\\unix\\Common\\Uin.c
Uin.c
..\\src\\unix\\Common\\Uin.c(14) : error C2375: 'Uin__ntohl' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(364) : see declaration of 'Ui
n__ntohl'
..\\src\\unix\\Common\\Uin.c(15) : error C2375: 'Uin__ntohs' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(365) : see declaration of 'Ui
n__ntohs'
..\\src\\unix\\Common\\Uin.c(16) : error C2375: 'Uin__htonl' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(366) : see declaration of 'Ui
n__htonl'
..\\src\\unix\\Common\\Uin.c(17) : error C2375: 'Uin__htons' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(367) : see declaration of 'Ui
n__htons'
  compile_c => 2
C compiler failed compiling: ..\src\unix\Common\Uin.c
new source -> compiling Usocket.c
cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
Oi -c ..\\src\\unix\\Common\\Usocket.c
Usocket.c
..\\src\\unix\\Common\\Usocket.c(65) : error C2375: 'Usocket__listen' : redefini
tion; different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(283) : see declaration of 'Us
ocket__listen'
..\\src\\unix\\Common\\Usocket.c(66) : error C2375: 'Usocket__shutdown' : redefi
nition; different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(284) : see declaration of 'Us
ocket__shutdown'
..\\src\\unix\\Common\\Usocket.c(67) : error C2375: 'Usocket__socket' : redefini
tion; different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(285) : see declaration of 'Us
ocket__socket'
  compile_c => 2
C compiler failed compiling: ..\src\unix\Common\Usocket.c
compilation failed => not building library "m3core.lib"
Fatal Error: package build failed

Regards,
Randy

-----Original Message-----
From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, May 21, 2010 12:44 AM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] m3core build failure


Oops, it should be include_dir.


32BITS is deliberate -- 32bits has a 32bit long, 64bits has a 64bit long, all Win32 platforms, 32bit or 64bit, have a 32bit long.


We really should just not have long anywhere, but that might be difficult to achieve.
   The often purported portable meaning of "long", that is a pointer-sized, is false.
The pointer sized integers are INTEGER and Word.T, not "long".



 - Jay

________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Fri, 21 May 2010 00:26:38 -0400
> Subject: [M3devel] m3core build failure
>
>
>
>
>
>
>
>
>
>
>
>
> I am getting a build error on Windows for m3core in HEAD branch:
>
>
>
>
>
> "C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
>
>
> unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading
>
>
>
>
>
> Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem. Shouldn't this be "NT386" instead of "WIN32"?
>
>
>
>
>
> Here is offending m3makefile:
>
>
>
>
>
> C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
>
>
> % Copyright (C) 1992, Digital Equipment Corporation
>
>
> % All rights reserved.
>
>
> % See the file COPYRIGHT for a full description.
>
>
> %
>
>
> % Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
>
>
> % modified on Wed Jun 9 17:25:51 PDT 1993 by harrison
>
>
> % modified on Thu May 6 12:11:46 PDT 1993 by muller
>
>
> % modified on Wed May 5 11:53:58 PDT 1993 by mjordan
>
>
>
>
>
> include_dir ("Common")
>
>
> include_dir (TARGET)
>
>
> if equal(OS_TYPE, "WIN32")
>
>
> % long is 32bits even on 64bit Windows
>
>
> include("32BITS")
>
>
> else
>
>
> include_dir (WORD_SIZE)
>
>
> end
>
>
>
>
>
> Regards,
>
>
> Randy
>
>
>
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation.
> If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately
> and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>
>
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical
> data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data
> may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will
> comply with all applicable ITAR, EAR and embargo compliance requirements.
>

CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s).  This email may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.


From jay.krell at cornell.edu  Fri May 21 07:11:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 05:11:07 +0000
Subject: [M3devel] m3core build failure
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8711C191D33D@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>,
	<COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8711C191D33D@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W31CE7568078110BBF4309AE6E40@phx.gbl>


I'll fix it later. Anything unix/common that doesn't compile for Win32, you can if out, even the whole directory. They aren't used currently.
 
 
 - Jay

----------------------------------------
> From: rcolebur at SCIRES.COM
> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> Date: Fri, 21 May 2010 01:00:17 -0400
> Subject: Re: [M3devel] m3core build failure
>
> Jay:
>
> Thanks for the reply.
>
> I don't think that is all that is wrong. I changed to "include_dir", but now I am getting other errors. For example:
>
> new source -> compiling UnixC.c
> cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
> n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
> on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
> src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
> Oi -c ..\\src\\unix\\Common\\UnixC.c
> UnixC.c
> ..\\src\\unix\\Common\\UnixC.c(95) : error C2375: 'Unix__open' : redefinition; d
> ifferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(329) : see declaration of 'Un
> ix__open'
> ..\\src\\unix\\Common\\UnixC.c(96) : error C2375: 'Unix__umask' : redefinition;
> different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(337) : see declaration of 'Un
> ix__umask'
> ..\\src\\unix\\Common\\UnixC.c(97) : error C2375: 'Unix__chmod' : redefinition;
> different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(357) : see declaration of 'Un
> ix__chmod'
> ..\\src\\unix\\Common\\UnixC.c(98) : error C2375: 'Unix__creat' : redefinition;
> different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(361) : see declaration of 'Un
> ix__creat'
> ..\\src\\unix\\Common\\UnixC.c(99) : error C2375: 'Unix__dup' : redefinition; di
> fferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(362) : see declaration of 'Un
> ix__dup'
> compile_c => 2
> C compiler failed compiling: ..\src\unix\Common\UnixC.c
> new source -> compiling Uin.c
> cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
> n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
> on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
> src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
> Oi -c ..\\src\\unix\\Common\\Uin.c
> Uin.c
> ..\\src\\unix\\Common\\Uin.c(14) : error C2375: 'Uin__ntohl' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(364) : see declaration of 'Ui
> n__ntohl'
> ..\\src\\unix\\Common\\Uin.c(15) : error C2375: 'Uin__ntohs' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(365) : see declaration of 'Ui
> n__ntohs'
> ..\\src\\unix\\Common\\Uin.c(16) : error C2375: 'Uin__htonl' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(366) : see declaration of 'Ui
> n__htonl'
> ..\\src\\unix\\Common\\Uin.c(17) : error C2375: 'Uin__htons' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(367) : see declaration of 'Ui
> n__htons'
> compile_c => 2
> C compiler failed compiling: ..\src\unix\Common\Uin.c
> new source -> compiling Usocket.c
> cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
> n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
> on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
> src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
> Oi -c ..\\src\\unix\\Common\\Usocket.c
> Usocket.c
> ..\\src\\unix\\Common\\Usocket.c(65) : error C2375: 'Usocket__listen' : redefini
> tion; different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(283) : see declaration of 'Us
> ocket__listen'
> ..\\src\\unix\\Common\\Usocket.c(66) : error C2375: 'Usocket__shutdown' : redefi
> nition; different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(284) : see declaration of 'Us
> ocket__shutdown'
> ..\\src\\unix\\Common\\Usocket.c(67) : error C2375: 'Usocket__socket' : redefini
> tion; different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(285) : see declaration of 'Us
> ocket__socket'
> compile_c => 2
> C compiler failed compiling: ..\src\unix\Common\Usocket.c
> compilation failed => not building library "m3core.lib"
> Fatal Error: package build failed
>
> Regards,
> Randy
>
> -----Original Message-----
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Friday, May 21, 2010 12:44 AM
> To: Coleburn, Randy; m3devel
> Subject: RE: [M3devel] m3core build failure
>
>
> Oops, it should be include_dir.
>
>
> 32BITS is deliberate -- 32bits has a 32bit long, 64bits has a 64bit long, all Win32 platforms, 32bit or 64bit, have a 32bit long.
>
>
> We really should just not have long anywhere, but that might be difficult to achieve.
> The often purported portable meaning of "long", that is a pointer-sized, is false.
> The pointer sized integers are INTEGER and Word.T, not "long".
>
>
>
> - Jay
>
> ________________________________
>> From: rcolebur at SCIRES.COM
>> To: m3devel at elegosoft.com
>> Date: Fri, 21 May 2010 00:26:38 -0400
>> Subject: [M3devel] m3core build failure
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I am getting a build error on Windows for m3core in HEAD branch:
>>
>>
>>
>>
>>
>> "C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
>>
>>
>> unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading
>>
>>
>>
>>
>>
>> Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem. Shouldn't this be "NT386" instead of "WIN32"?
>>
>>
>>
>>
>>
>> Here is offending m3makefile:
>>
>>
>>
>>
>>
>> C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
>>
>>
>> % Copyright (C) 1992, Digital Equipment Corporation
>>
>>
>> % All rights reserved.
>>
>>
>> % See the file COPYRIGHT for a full description.
>>
>>
>> %
>>
>>
>> % Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
>>
>>
>> % modified on Wed Jun 9 17:25:51 PDT 1993 by harrison
>>
>>
>> % modified on Thu May 6 12:11:46 PDT 1993 by muller
>>
>>
>> % modified on Wed May 5 11:53:58 PDT 1993 by mjordan
>>
>>
>>
>>
>>
>> include_dir ("Common")
>>
>>
>> include_dir (TARGET)
>>
>>
>> if equal(OS_TYPE, "WIN32")
>>
>>
>> % long is 32bits even on 64bit Windows
>>
>>
>> include("32BITS")
>>
>>
>> else
>>
>>
>> include_dir (WORD_SIZE)
>>
>>
>> end
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>> Randy
>>
>>
>>
>>
>> ________________________________
>>
>> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation.
>> If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately
>> and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>>
>>
>>
>> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical
>> data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data
>> may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will
>> comply with all applicable ITAR, EAR and embargo compliance requirements.
>>
>
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. 		 	   		  

From mika at async.async.caltech.edu  Fri May 21 07:37:56 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 20 May 2010 22:37:56 -0700
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl> 
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, ,
	<4BF56D60.2000403@lcwb.coop>,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>
Message-ID: <20100521053756.D74951A2094@async.async.caltech.edu>


As I recall it the "Dragon Book" has a whole section on this topic of
nested functions in Pascal.  Including Dijkstra's "display".  I'm not
an expert, just remember reading it.  Wirth also talks about it in his
"Good Ideas, Through the Looking Glass" (where he says the display
might be a pessimization).

     Mika

Jay K writes:
>
>Maybe we can/should transform into one of the forms I show and dispense wit=
>h any gcc support?
>At the cost of losing some "easy" optimization..of nested functions?
>  "easy" as in=2C occurs even without -O2=2C but might occur with -O2?
>=20
>=20
>I know what you mean -- NT386 passes the static link in ecx.
>This is "ok" because in C++ the "this" pointer is passed in ecx.
>=20
>=20
>Passing it as "just" another parameter might be less efficient=2C but ok?
>  And really=2C it'd only be less efficient on one architecture -- 32bit x8=
>6.
>  And maybe not all x86s -- depending on if some ABIs have a register based=
> calling convention.
>=20
>=20
>We don't need any actual ABI-compatibility with anything here=2C do we?
>=20
>=20
> - Jay
>
>
>----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu=2C 20 May 2010 22:22:46 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>> That is the standard formulation=2C but different architectures have diff=
>erent optimised forms (passing static link in a register=2C etc.). In any c=
>ase=2C gcc has its own weird way of doing things=2C which we mostly use=2C =
>but from which we need a little extra support (hence the small amount of sp=
>ecial tailoring).
>>
>> On 20 May 2010=2C at 21:43=2C Jay K wrote:
>>
>>>
>>> Wierd. To me the model to follow is almost obvious. It should be obvious=
> to everyone and implemented the way I have in mind. :)
>>>
>>>
>>> The static link is an extra parameter.
>>> And=2C as such=2C also an extra local variable.
>>> You only need one.
>>> Each nesting level would follow another chain.
>>> Or you can pass each nesting level as an extra parameter.
>>> Or you can optimize and pass locals/parameters separately.
>>> But there is an obvious straightforward non-optimized form. ?
>>>
>>>
>>> Here=2C I worked it through:
>>>
>>>
>>>
>>> Why doesn't it just look something like this:
>>>
>>>
>>> nested:
>>>
>>> void F1(int a=2C int b)
>>> {
>>> int c =3D a + b=3B
>>>
>>> int f2()
>>> {
>>> int d =3D a + b=3B
>>>
>>> int f3()
>>> {
>>> return d + a + c=3B
>>> }
>>>
>>> return a + c + f3()=3B
>>> }
>>>
>>> return f2()=3B
>>> }
>>>
>>> not nested:
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int d=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> f1_frame_t* f1=3B
>>> } f2_frame_t=3B
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int c=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> int a=3B
>>> int b=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2)
>>> {
>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>> }
>>>
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> int d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> int c =3D a + b=3B
>>> return f2((f1_frame_t*)&c)=3B
>>> }
>>>
>>>
>>> or=2C alernatively=2C almost the same=2C pass each chain as another para=
>meter:
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int d=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> } f2_frame_t=3B
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int c=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> int a=3B
>>> int b=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>> {
>>> return f2->d + f1->a + f1->c=3B
>>> }
>>>
>>>
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> int d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3((f2_frame_t*)&d=2C f1)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> int c =3D a + b=3B
>>> return f2((f1_frame_t*)&c)=3B
>>> }
>>>
>>>
>>> This should be easily adapted to any function call convention/sequence.
>>> e.g. even if parameters are passed in registers.
>>>
>>>
>>> And for that matter=2C why don't we just transform it to be like this?
>>> With the goal of reducing/eliminating gcc patches?
>>>
>>>
>>> Am I missing something?
>>>
>>>
>>> This form doesn't work?
>>>
>>>
>>> Isn't reasonably simple?
>>>
>>>
>>> Granted it might not be optimal. But it depends.
>>> You know=2C you can copy in the local/parameter values=2C but then you h=
>ave
>>> to copy them out too. You can do analysis to show they aren't changed=2C
>>> in which case no need to copy them out.
>>> Similarly you can pass the parameters as separate parameters=2C by addre=
>ss
>>> if they are ever changed.
>>>
>>>
>>> A portable transform couldn't depend on adjacency of locals and paramete=
>rs.
>>> It would have to either copy the parameters into the frame_t=2C or their=
> addresses.
>>>
>>>
>>> A portable form couldn't get the frame by taking the address of a "indiv=
>idual" local.
>>>
>>>
>>> Here is portable form:
>>>
>>>
>>> typedef struct {
>>> int d=3B
>>> f1_frame_t* f1=3B
>>> } f2_frame_t=3B
>>>
>>> typedef struct {
>>> int a=3B
>>> int b=3B
>>> int c=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2)
>>> {
>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>> }
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> f2_frame_t f=3B
>>> f.f1 =3D f1=3B
>>> f.d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3(&f)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> f1_frame_t f=3B
>>> f.a =3D a=3B
>>> f.b =3D b=3B
>>> f.c =3D a + b=3B
>>> return f2(&f)=3B
>>> }
>>>
>>>
>>> or:
>>>
>>>
>>> typedef struct {
>>> int d=3B
>>> } f2_frame_t=3B
>>>
>>>
>>> typedef struct {
>>> int a=3B
>>> int b=3B
>>> int c=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>> {
>>> return f2->d + f1->a + f1->c=3B
>>> }
>>>
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> f2_frame_t f=3B
>>> f.d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3(&f=2C f1)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> f1_frame_t f=3B
>>> f.a =3D a=3B
>>> f.b =3D b=3B
>>> f.c =3D a + b=3B
>>> return f2(&f)=3B
>>> }
>>>
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Date: Thu=2C 20 May 2010 12:12:00 -0500
>>>> From: rodney_bates at lcwb.coop
>>>> To: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>
>>>> gcc even extends C with nested functions=2C and the support is there fo=
>r that. We use it too.
>>>>
>>>> Beware: The runtime model is=2C IMO=2C bizarre. Definitely counterintui=
>tive and unlike anything
>>>> you will ever see elsewhere. There are two static links. One is used fo=
>r the first step
>>>> in following a static chain and points to the expected place in the tar=
>get frame. The other
>>>> is used of subsequent steps in chain-following=2C and points to somewhe=
>re inside the target
>>>> frame that is dependent on the target procedure. It's the beginning of =
>a subrecord where
>>>> all the nonlocally-referenced variables are collected. The second stati=
>c link is also
>>>> located in there. All the nonlocally-referenced variables and parameter=
>s are duplicated
>>>> in there too.
>>>>
>>>> I'm not sure I remembered these details exactly right. Maybe both links=
> point to the
>>>> subrecord=2C but one is located at a traditional procedure-independent=
>=2C fixed location
>>>> in the frame=2C while the second is located in the subrecord. Also=2C s=
>ometimes the first
>>>> static link value is kept in a register and never stored.
>>>>
>>>> What this all apparently accomplishes is simplifying an "insanely compl=
>icated" _compile-time_
>>>> scheme that=2C I believe came from interaction between nested procedure=
>s and inlining them.
>>>>
>>>> But it's at the cost of what I would call an insanely complicated _runt=
>ime_ scheme.
>>>>
>>>> It undermined m3gdb's handling of static links=2C and I don't think it'=
>s possible to fix
>>>> with the current design of emitting debug info very early. The location=
>s and target
>>>> offsets of these things aren't know until later=2C and m3gdb really nee=
>ds to know them.
>>>>
>>>>
>>>> Jay K wrote:
>>>>> What I meant regarding "static chain" was more like "does gcc already =
>have support that we can use".
>>>>> Don't any of the other languages need it already?
>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>
>>>>> - Jay
>>>>>
>> 		 	   		  =


From jay.krell at cornell.edu  Fri May 21 08:41:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 06:41:42 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <20100521053756.D74951A2094@async.async.caltech.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , ,
	,,<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	,,<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	,,<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	,,<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	, , <4BF56D60.2000403@lcwb.coop>, ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>,
	<20100521053756.D74951A2094@async.async.caltech.edu>
Message-ID: <COL101-W62B5841AA922ECC333168E6E40@phx.gbl>


Thanks for the reference!
 
search for "Good Ideas, Through the Looking Glass"
finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_origFig.pdf"
(I don't need to provide the link really.)
 
 - Jay

----------------------------------------
> To: jay.krell at cornell.edu
> Date: Thu, 20 May 2010 22:37:56 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
>
> As I recall it the "Dragon Book" has a whole section on this topic of
> nested functions in Pascal. Including Dijkstra's "display". I'm not
> an expert, just remember reading it. Wirth also talks about it in his
> "Good Ideas, Through the Looking Glass" (where he says the display
> might be a pessimization).
>
> Mika
>
> Jay K writes:
>>
>>Maybe we can/should transform into one of the forms I show and dispense wit=
>>h any gcc support?
>>At the cost of losing some "easy" optimization..of nested functions?
>> "easy" as in=2C occurs even without -O2=2C but might occur with -O2?
>>=20
>>=20
>>I know what you mean -- NT386 passes the static link in ecx.
>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>=20
>>=20
>>Passing it as "just" another parameter might be less efficient=2C but ok?
>> And really=2C it'd only be less efficient on one architecture -- 32bit x8=
>>6.
>> And maybe not all x86s -- depending on if some ABIs have a register based=
>> calling convention.
>>=20
>>=20
>>We don't need any actual ABI-compatibility with anything here=2C do we?
>>=20
>>=20
>> - Jay
>>
>>
>>----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Thu=2C 20 May 2010 22:22:46 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>> That is the standard formulation=2C but different architectures have diff=
>>erent optimised forms (passing static link in a register=2C etc.). In any c=
>>ase=2C gcc has its own weird way of doing things=2C which we mostly use=2C =
>>but from which we need a little extra support (hence the small amount of sp=
>>ecial tailoring).
>>>
>>> On 20 May 2010=2C at 21:43=2C Jay K wrote:
>>>
>>>>
>>>> Wierd. To me the model to follow is almost obvious. It should be obvious=
>> to everyone and implemented the way I have in mind. :)
>>>>
>>>>
>>>> The static link is an extra parameter.
>>>> And=2C as such=2C also an extra local variable.
>>>> You only need one.
>>>> Each nesting level would follow another chain.
>>>> Or you can pass each nesting level as an extra parameter.
>>>> Or you can optimize and pass locals/parameters separately.
>>>> But there is an obvious straightforward non-optimized form. ?
>>>>
>>>>
>>>> Here=2C I worked it through:
>>>>
>>>>
>>>>
>>>> Why doesn't it just look something like this:
>>>>
>>>>
>>>> nested:
>>>>
>>>> void F1(int a=2C int b)
>>>> {
>>>> int c =3D a + b=3B
>>>>
>>>> int f2()
>>>> {
>>>> int d =3D a + b=3B
>>>>
>>>> int f3()
>>>> {
>>>> return d + a + c=3B
>>>> }
>>>>
>>>> return a + c + f3()=3B
>>>> }
>>>>
>>>> return f2()=3B
>>>> }
>>>>
>>>> not nested:
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int d=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> f1_frame_t* f1=3B
>>>> } f2_frame_t=3B
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int c=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> int a=3B
>>>> int b=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2)
>>>> {
>>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>>> }
>>>>
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> int d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> int c =3D a + b=3B
>>>> return f2((f1_frame_t*)&c)=3B
>>>> }
>>>>
>>>>
>>>> or=2C alernatively=2C almost the same=2C pass each chain as another para=
>>meter:
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int d=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> } f2_frame_t=3B
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int c=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> int a=3B
>>>> int b=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>>> {
>>>> return f2->d + f1->a + f1->c=3B
>>>> }
>>>>
>>>>
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> int d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=2C f1)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> int c =3D a + b=3B
>>>> return f2((f1_frame_t*)&c)=3B
>>>> }
>>>>
>>>>
>>>> This should be easily adapted to any function call convention/sequence.
>>>> e.g. even if parameters are passed in registers.
>>>>
>>>>
>>>> And for that matter=2C why don't we just transform it to be like this?
>>>> With the goal of reducing/eliminating gcc patches?
>>>>
>>>>
>>>> Am I missing something?
>>>>
>>>>
>>>> This form doesn't work?
>>>>
>>>>
>>>> Isn't reasonably simple?
>>>>
>>>>
>>>> Granted it might not be optimal. But it depends.
>>>> You know=2C you can copy in the local/parameter values=2C but then you h=
>>ave
>>>> to copy them out too. You can do analysis to show they aren't changed=2C
>>>> in which case no need to copy them out.
>>>> Similarly you can pass the parameters as separate parameters=2C by addre=
>>ss
>>>> if they are ever changed.
>>>>
>>>>
>>>> A portable transform couldn't depend on adjacency of locals and paramete=
>>rs.
>>>> It would have to either copy the parameters into the frame_t=2C or their=
>> addresses.
>>>>
>>>>
>>>> A portable form couldn't get the frame by taking the address of a "indiv=
>>idual" local.
>>>>
>>>>
>>>> Here is portable form:
>>>>
>>>>
>>>> typedef struct {
>>>> int d=3B
>>>> f1_frame_t* f1=3B
>>>> } f2_frame_t=3B
>>>>
>>>> typedef struct {
>>>> int a=3B
>>>> int b=3B
>>>> int c=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2)
>>>> {
>>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>>> }
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> f2_frame_t f=3B
>>>> f.f1 =3D f1=3B
>>>> f.d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3(&f)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> f1_frame_t f=3B
>>>> f.a =3D a=3B
>>>> f.b =3D b=3B
>>>> f.c =3D a + b=3B
>>>> return f2(&f)=3B
>>>> }
>>>>
>>>>
>>>> or:
>>>>
>>>>
>>>> typedef struct {
>>>> int d=3B
>>>> } f2_frame_t=3B
>>>>
>>>>
>>>> typedef struct {
>>>> int a=3B
>>>> int b=3B
>>>> int c=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>>> {
>>>> return f2->d + f1->a + f1->c=3B
>>>> }
>>>>
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> f2_frame_t f=3B
>>>> f.d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3(&f=2C f1)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> f1_frame_t f=3B
>>>> f.a =3D a=3B
>>>> f.b =3D b=3B
>>>> f.c =3D a + b=3B
>>>> return f2(&f)=3B
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Thu=2C 20 May 2010 12:12:00 -0500
>>>>> From: rodney_bates at lcwb.coop
>>>>> To: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>
>>>>> gcc even extends C with nested functions=2C and the support is there fo=
>>r that. We use it too.
>>>>>
>>>>> Beware: The runtime model is=2C IMO=2C bizarre. Definitely counterintui=
>>tive and unlike anything
>>>>> you will ever see elsewhere. There are two static links. One is used fo=
>>r the first step
>>>>> in following a static chain and points to the expected place in the tar=
>>get frame. The other
>>>>> is used of subsequent steps in chain-following=2C and points to somewhe=
>>re inside the target
>>>>> frame that is dependent on the target procedure. It's the beginning of =
>>a subrecord where
>>>>> all the nonlocally-referenced variables are collected. The second stati=
>>c link is also
>>>>> located in there. All the nonlocally-referenced variables and parameter=
>>s are duplicated
>>>>> in there too.
>>>>>
>>>>> I'm not sure I remembered these details exactly right. Maybe both links=
>> point to the
>>>>> subrecord=2C but one is located at a traditional procedure-independent=
>>=2C fixed location
>>>>> in the frame=2C while the second is located in the subrecord. Also=2C s=
>>ometimes the first
>>>>> static link value is kept in a register and never stored.
>>>>>
>>>>> What this all apparently accomplishes is simplifying an "insanely compl=
>>icated" _compile-time_
>>>>> scheme that=2C I believe came from interaction between nested procedure=
>>s and inlining them.
>>>>>
>>>>> But it's at the cost of what I would call an insanely complicated _runt=
>>ime_ scheme.
>>>>>
>>>>> It undermined m3gdb's handling of static links=2C and I don't think it'=
>>s possible to fix
>>>>> with the current design of emitting debug info very early. The location=
>>s and target
>>>>> offsets of these things aren't know until later=2C and m3gdb really nee=
>>ds to know them.
>>>>>
>>>>>
>>>>> Jay K wrote:
>>>>>> What I meant regarding "static chain" was more like "does gcc already =
>>have support that we can use".
>>>>>> Don't any of the other languages need it already?
>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>
>>>>>> - Jay
>>>>>>
>>> = 		 	   		  

From mika at async.async.caltech.edu  Fri May 21 08:45:22 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 20 May 2010 23:45:22 -0700
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W62B5841AA922ECC333168E6E40@phx.gbl> 
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, , ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, , ,
	<4BF56D60.2000403@lcwb.coop>, ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>,
	<20100521053756.D74951A2094@async.async.caltech.edu>
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>
Message-ID: <20100521064522.93AAC1A2094@async.async.caltech.edu>

The Dragon Book is 

Aho, Sethi, Ullman.  Compilers: Principles, Techniques, and Tools.
Addison-Wesley, 1988.  Chapter 7, esp. Sec. 7.4.

   Mika

Jay K writes:
>
>Thanks for the reference!
>=20
>search for "Good Ideas=2C Through the Looking Glass"
>finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_o=
>rigFig.pdf"
>(I don't need to provide the link really.)
>=20
> - Jay
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Thu=2C 20 May 2010 22:37:56 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>>
>> As I recall it the "Dragon Book" has a whole section on this topic of
>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>> an expert=2C just remember reading it. Wirth also talks about it in his
>> "Good Ideas=2C Through the Looking Glass" (where he says the display
>> might be a pessimization).
>>
>> Mika
>>
>> Jay K writes:
>>>
>>>Maybe we can/should transform into one of the forms I show and dispense w=
>it=3D
>>>h any gcc support?
>>>At the cost of losing some "easy" optimization..of nested functions?
>>> "easy" as in=3D2C occurs even without -O2=3D2C but might occur with -O2?
>>>=3D20
>>>=3D20
>>>I know what you mean -- NT386 passes the static link in ecx.
>>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>=3D20
>>>=3D20
>>>Passing it as "just" another parameter might be less efficient=3D2C but o=
>k?
>>> And really=3D2C it'd only be less efficient on one architecture -- 32bit=
> x8=3D
>>>6.
>>> And maybe not all x86s -- depending on if some ABIs have a register base=
>d=3D
>>> calling convention.
>>>=3D20
>>>=3D20
>>>We don't need any actual ABI-compatibility with anything here=3D2C do we?
>>>=3D20
>>>=3D20
>>> - Jay
>>>
>>>
>>>----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Thu=3D2C 20 May 2010 22:22:46 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>
>>>> That is the standard formulation=3D2C but different architectures have =
>diff=3D
>>>erent optimised forms (passing static link in a register=3D2C etc.). In a=
>ny c=3D
>>>ase=3D2C gcc has its own weird way of doing things=3D2C which we mostly u=
>se=3D2C =3D
>>>but from which we need a little extra support (hence the small amount of =
>sp=3D
>>>ecial tailoring).
>>>>
>>>> On 20 May 2010=3D2C at 21:43=3D2C Jay K wrote:
>>>>
>>>>>
>>>>> Wierd. To me the model to follow is almost obvious. It should be obvio=
>us=3D
>>> to everyone and implemented the way I have in mind. :)
>>>>>
>>>>>
>>>>> The static link is an extra parameter.
>>>>> And=3D2C as such=3D2C also an extra local variable.
>>>>> You only need one.
>>>>> Each nesting level would follow another chain.
>>>>> Or you can pass each nesting level as an extra parameter.
>>>>> Or you can optimize and pass locals/parameters separately.
>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>
>>>>>
>>>>> Here=3D2C I worked it through:
>>>>>
>>>>>
>>>>>
>>>>> Why doesn't it just look something like this:
>>>>>
>>>>>
>>>>> nested:
>>>>>
>>>>> void F1(int a=3D2C int b)
>>>>> {
>>>>> int c =3D3D a + b=3D3B
>>>>>
>>>>> int f2()
>>>>> {
>>>>> int d =3D3D a + b=3D3B
>>>>>
>>>>> int f3()
>>>>> {
>>>>> return d + a + c=3D3B
>>>>> }
>>>>>
>>>>> return a + c + f3()=3D3B
>>>>> }
>>>>>
>>>>> return f2()=3D3B
>>>>> }
>>>>>
>>>>> not nested:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int d=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> f1_frame_t* f1=3D3B
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int c=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2)
>>>>> {
>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> int c =3D3D a + b=3D3B
>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> or=3D2C alernatively=3D2C almost the same=3D2C pass each chain as anot=
>her para=3D
>>>meter:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int d=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int c=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>> {
>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D2C f1)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> int c =3D3D a + b=3D3B
>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> This should be easily adapted to any function call convention/sequence=
>.
>>>>> e.g. even if parameters are passed in registers.
>>>>>
>>>>>
>>>>> And for that matter=3D2C why don't we just transform it to be like thi=
>s?
>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>>
>>>>> This form doesn't work?
>>>>>
>>>>>
>>>>> Isn't reasonably simple?
>>>>>
>>>>>
>>>>> Granted it might not be optimal. But it depends.
>>>>> You know=3D2C you can copy in the local/parameter values=3D2C but then=
> you h=3D
>>>ave
>>>>> to copy them out too. You can do analysis to show they aren't changed=
>=3D2C
>>>>> in which case no need to copy them out.
>>>>> Similarly you can pass the parameters as separate parameters=3D2C by a=
>ddre=3D
>>>ss
>>>>> if they are ever changed.
>>>>>
>>>>>
>>>>> A portable transform couldn't depend on adjacency of locals and parame=
>te=3D
>>>rs.
>>>>> It would have to either copy the parameters into the frame_t=3D2C or t=
>heir=3D
>>> addresses.
>>>>>
>>>>>
>>>>> A portable form couldn't get the frame by taking the address of a "ind=
>iv=3D
>>>idual" local.
>>>>>
>>>>>
>>>>> Here is portable form:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> int d=3D3B
>>>>> f1_frame_t* f1=3D3B
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>> typedef struct {
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> int c=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2)
>>>>> {
>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>> }
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> f2_frame_t f=3D3B
>>>>> f.f1 =3D3D f1=3D3B
>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3(&f)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> f1_frame_t f=3D3B
>>>>> f.a =3D3D a=3D3B
>>>>> f.b =3D3D b=3D3B
>>>>> f.c =3D3D a + b=3D3B
>>>>> return f2(&f)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> or:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> int d=3D3B
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> int c=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>> {
>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> f2_frame_t f=3D3B
>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3(&f=3D2C f1)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> f1_frame_t f=3D3B
>>>>> f.a =3D3D a=3D3B
>>>>> f.b =3D3D b=3D3B
>>>>> f.c =3D3D a + b=3D3B
>>>>> return f2(&f)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> Date: Thu=3D2C 20 May 2010 12:12:00 -0500
>>>>>> From: rodney_bates at lcwb.coop
>>>>>> To: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>
>>>>>> gcc even extends C with nested functions=3D2C and the support is ther=
>e fo=3D
>>>r that. We use it too.
>>>>>>
>>>>>> Beware: The runtime model is=3D2C IMO=3D2C bizarre. Definitely counte=
>rintui=3D
>>>tive and unlike anything
>>>>>> you will ever see elsewhere. There are two static links. One is used =
>fo=3D
>>>r the first step
>>>>>> in following a static chain and points to the expected place in the t=
>ar=3D
>>>get frame. The other
>>>>>> is used of subsequent steps in chain-following=3D2C and points to som=
>ewhe=3D
>>>re inside the target
>>>>>> frame that is dependent on the target procedure. It's the beginning o=
>f =3D
>>>a subrecord where
>>>>>> all the nonlocally-referenced variables are collected. The second sta=
>ti=3D
>>>c link is also
>>>>>> located in there. All the nonlocally-referenced variables and paramet=
>er=3D
>>>s are duplicated
>>>>>> in there too.
>>>>>>
>>>>>> I'm not sure I remembered these details exactly right. Maybe both lin=
>ks=3D
>>> point to the
>>>>>> subrecord=3D2C but one is located at a traditional procedure-independ=
>ent=3D
>>>=3D2C fixed location
>>>>>> in the frame=3D2C while the second is located in the subrecord. Also=
>=3D2C s=3D
>>>ometimes the first
>>>>>> static link value is kept in a register and never stored.
>>>>>>
>>>>>> What this all apparently accomplishes is simplifying an "insanely com=
>pl=3D
>>>icated" _compile-time_
>>>>>> scheme that=3D2C I believe came from interaction between nested proce=
>dure=3D
>>>s and inlining them.
>>>>>>
>>>>>> But it's at the cost of what I would call an insanely complicated _ru=
>nt=3D
>>>ime_ scheme.
>>>>>>
>>>>>> It undermined m3gdb's handling of static links=3D2C and I don't think=
> it'=3D
>>>s possible to fix
>>>>>> with the current design of emitting debug info very early. The locati=
>on=3D
>>>s and target
>>>>>> offsets of these things aren't know until later=3D2C and m3gdb really=
> nee=3D
>>>ds to know them.
>>>>>>
>>>>>>
>>>>>> Jay K wrote:
>>>>>>> What I meant regarding "static chain" was more like "does gcc alread=
>y =3D
>>>have support that we can use".
>>>>>>> Don't any of the other languages need it already?
>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>> =3D 		 	   		  =


From jay.krell at cornell.edu  Fri May 21 09:41:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 07:41:46 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <20100521064522.93AAC1A2094@async.async.caltech.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , ,
	,,<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , ,
	,,<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , ,
	,,<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, ,
	,,<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, ,
	,,<4BF56D60.2000403@lcwb.coop>,
	,,<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>,
	, , <AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>, ,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>, ,
	<20100521053756.D74951A2094@async.async.caltech.edu>,
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>,
	<20100521064522.93AAC1A2094@async.async.caltech.edu>
Message-ID: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>


Of course. I tried to read it as a teenager and got stuck on the automata stuff.
 
 
Wirth isn't 100% clear to me.
 He describes my two schemes.
 I think he throws out the second as an unimportant optimization.
 He criticizes the first as inefficient, granted.
 What I don't get is the static link in addition to the dynamic link.
 Perhaps I have not accounted for recursion.
 
 
Oh..I see..he is allowing to take the address of a nested function.
I didn't account for that.
I still don't understand all the arrow he draws for the static link, but
I do see that my scheme doesn't suffice.
Taking the address of a nested function..doesn't seem like a good idea.
Maybe I'm too C-minded.
 
 
My prototypical favorite Scheme example is:
 
 
(define (make-adder x)
   (define (add y) (+ x y))
   add)
 
 
(define add2 (make-adder 2))
(add2 3) => 5
 
 
but Modula-3 doesn't allow for that anyway..
 
Still, we make "closures": tuple{-1, function pointer, frame pointer}
before calling a pointer, we check if it points to -1, and if so
we call function pointer with frame pointer as the link.
 
 
And then I guess, you might have something like this?
 
 
 
int F1(int a, int b, int (*F)())
{
  int F2()
  {
    return a + b;
  }
 
  if (F != NULL)
   return F();
 
  return F1(a - 1, b - 1, &F2);
 
}
 
 
F(1, 2, NULL) => 3
 
 
Though that doesn't demonstrate the generality perhaps.
 
 
Taking the address of a nested function seems dubious.
 
 
My "favorite" bit of Schema:
 
(define (make-adder x)
   (define (add y) (+ x y))
   add)
 
 
(define add2 (make-adder 2))
 
(add2 3) => 3
 
 
But we don't allow that sort of thing -- frames are always stack allocated.
 
 
 
 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Thu, 20 May 2010 23:45:22 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> The Dragon Book is
>
> Aho, Sethi, Ullman. Compilers: Principles, Techniques, and Tools.
> Addison-Wesley, 1988. Chapter 7, esp. Sec. 7.4.
>
> Mika
>
> Jay K writes:
>>
>>Thanks for the reference!
>>=20
>>search for "Good Ideas=2C Through the Looking Glass"
>>finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_o=
>>rigFig.pdf"
>>(I don't need to provide the link really.)
>>=20
>> - Jay
>>
>>----------------------------------------
>>> To: jay.krell at cornell.edu
>>> Date: Thu=2C 20 May 2010 22:37:56 -0700
>>> From: mika at async.async.caltech.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>>
>>> As I recall it the "Dragon Book" has a whole section on this topic of
>>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>>> an expert=2C just remember reading it. Wirth also talks about it in his
>>> "Good Ideas=2C Through the Looking Glass" (where he says the display
>>> might be a pessimization).
>>>
>>> Mika
>>>
>>> Jay K writes:
>>>>
>>>>Maybe we can/should transform into one of the forms I show and dispense w=
>>it=3D
>>>>h any gcc support?
>>>>At the cost of losing some "easy" optimization..of nested functions?
>>>> "easy" as in=3D2C occurs even without -O2=3D2C but might occur with -O2?
>>>>=3D20
>>>>=3D20
>>>>I know what you mean -- NT386 passes the static link in ecx.
>>>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>>=3D20
>>>>=3D20
>>>>Passing it as "just" another parameter might be less efficient=3D2C but o=
>>k?
>>>> And really=3D2C it'd only be less efficient on one architecture -- 32bit=
>> x8=3D
>>>>6.
>>>> And maybe not all x86s -- depending on if some ABIs have a register base=
>>d=3D
>>>> calling convention.
>>>>=3D20
>>>>=3D20
>>>>We don't need any actual ABI-compatibility with anything here=3D2C do we?
>>>>=3D20
>>>>=3D20
>>>> - Jay
>>>>
>>>>
>>>>----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Thu=3D2C 20 May 2010 22:22:46 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>
>>>>> That is the standard formulation=3D2C but different architectures have =
>>diff=3D
>>>>erent optimised forms (passing static link in a register=3D2C etc.). In a=
>>ny c=3D
>>>>ase=3D2C gcc has its own weird way of doing things=3D2C which we mostly u=
>>se=3D2C =3D
>>>>but from which we need a little extra support (hence the small amount of =
>>sp=3D
>>>>ecial tailoring).
>>>>>
>>>>> On 20 May 2010=3D2C at 21:43=3D2C Jay K wrote:
>>>>>
>>>>>>
>>>>>> Wierd. To me the model to follow is almost obvious. It should be obvio=
>>us=3D
>>>> to everyone and implemented the way I have in mind. :)
>>>>>>
>>>>>>
>>>>>> The static link is an extra parameter.
>>>>>> And=3D2C as such=3D2C also an extra local variable.
>>>>>> You only need one.
>>>>>> Each nesting level would follow another chain.
>>>>>> Or you can pass each nesting level as an extra parameter.
>>>>>> Or you can optimize and pass locals/parameters separately.
>>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>>
>>>>>>
>>>>>> Here=3D2C I worked it through:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Why doesn't it just look something like this:
>>>>>>
>>>>>>
>>>>>> nested:
>>>>>>
>>>>>> void F1(int a=3D2C int b)
>>>>>> {
>>>>>> int c =3D3D a + b=3D3B
>>>>>>
>>>>>> int f2()
>>>>>> {
>>>>>> int d =3D3D a + b=3D3B
>>>>>>
>>>>>> int f3()
>>>>>> {
>>>>>> return d + a + c=3D3B
>>>>>> }
>>>>>>
>>>>>> return a + c + f3()=3D3B
>>>>>> }
>>>>>>
>>>>>> return f2()=3D3B
>>>>>> }
>>>>>>
>>>>>> not nested:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int d=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> f1_frame_t* f1=3D3B
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int c=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2)
>>>>>> {
>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> int c =3D3D a + b=3D3B
>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> or=3D2C alernatively=3D2C almost the same=3D2C pass each chain as anot=
>>her para=3D
>>>>meter:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int d=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int c=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>> {
>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D2C f1)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> int c =3D3D a + b=3D3B
>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> This should be easily adapted to any function call convention/sequence=
>>.
>>>>>> e.g. even if parameters are passed in registers.
>>>>>>
>>>>>>
>>>>>> And for that matter=3D2C why don't we just transform it to be like thi=
>>s?
>>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>>
>>>>>>
>>>>>> Am I missing something?
>>>>>>
>>>>>>
>>>>>> This form doesn't work?
>>>>>>
>>>>>>
>>>>>> Isn't reasonably simple?
>>>>>>
>>>>>>
>>>>>> Granted it might not be optimal. But it depends.
>>>>>> You know=3D2C you can copy in the local/parameter values=3D2C but then=
>> you h=3D
>>>>ave
>>>>>> to copy them out too. You can do analysis to show they aren't changed=
>>=3D2C
>>>>>> in which case no need to copy them out.
>>>>>> Similarly you can pass the parameters as separate parameters=3D2C by a=
>>ddre=3D
>>>>ss
>>>>>> if they are ever changed.
>>>>>>
>>>>>>
>>>>>> A portable transform couldn't depend on adjacency of locals and parame=
>>te=3D
>>>>rs.
>>>>>> It would have to either copy the parameters into the frame_t=3D2C or t=
>>heir=3D
>>>> addresses.
>>>>>>
>>>>>>
>>>>>> A portable form couldn't get the frame by taking the address of a "ind=
>>iv=3D
>>>>idual" local.
>>>>>>
>>>>>>
>>>>>> Here is portable form:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> int d=3D3B
>>>>>> f1_frame_t* f1=3D3B
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>> typedef struct {
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> int c=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2)
>>>>>> {
>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> f2_frame_t f=3D3B
>>>>>> f.f1 =3D3D f1=3D3B
>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3(&f)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> f1_frame_t f=3D3B
>>>>>> f.a =3D3D a=3D3B
>>>>>> f.b =3D3D b=3D3B
>>>>>> f.c =3D3D a + b=3D3B
>>>>>> return f2(&f)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> or:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> int d=3D3B
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> int c=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>> {
>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> f2_frame_t f=3D3B
>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3(&f=3D2C f1)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> f1_frame_t f=3D3B
>>>>>> f.a =3D3D a=3D3B
>>>>>> f.b =3D3D b=3D3B
>>>>>> f.c =3D3D a + b=3D3B
>>>>>> return f2(&f)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> Date: Thu=3D2C 20 May 2010 12:12:00 -0500
>>>>>>> From: rodney_bates at lcwb.coop
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>>
>>>>>>> gcc even extends C with nested functions=3D2C and the support is ther=
>>e fo=3D
>>>>r that. We use it too.
>>>>>>>
>>>>>>> Beware: The runtime model is=3D2C IMO=3D2C bizarre. Definitely counte=
>>rintui=3D
>>>>tive and unlike anything
>>>>>>> you will ever see elsewhere. There are two static links. One is used =
>>fo=3D
>>>>r the first step
>>>>>>> in following a static chain and points to the expected place in the t=
>>ar=3D
>>>>get frame. The other
>>>>>>> is used of subsequent steps in chain-following=3D2C and points to som=
>>ewhe=3D
>>>>re inside the target
>>>>>>> frame that is dependent on the target procedure. It's the beginning o=
>>f =3D
>>>>a subrecord where
>>>>>>> all the nonlocally-referenced variables are collected. The second sta=
>>ti=3D
>>>>c link is also
>>>>>>> located in there. All the nonlocally-referenced variables and paramet=
>>er=3D
>>>>s are duplicated
>>>>>>> in there too.
>>>>>>>
>>>>>>> I'm not sure I remembered these details exactly right. Maybe both lin=
>>ks=3D
>>>> point to the
>>>>>>> subrecord=3D2C but one is located at a traditional procedure-independ=
>>ent=3D
>>>>=3D2C fixed location
>>>>>>> in the frame=3D2C while the second is located in the subrecord. Also=
>>=3D2C s=3D
>>>>ometimes the first
>>>>>>> static link value is kept in a register and never stored.
>>>>>>>
>>>>>>> What this all apparently accomplishes is simplifying an "insanely com=
>>pl=3D
>>>>icated" _compile-time_
>>>>>>> scheme that=3D2C I believe came from interaction between nested proce=
>>dure=3D
>>>>s and inlining them.
>>>>>>>
>>>>>>> But it's at the cost of what I would call an insanely complicated _ru=
>>nt=3D
>>>>ime_ scheme.
>>>>>>>
>>>>>>> It undermined m3gdb's handling of static links=3D2C and I don't think=
>> it'=3D
>>>>s possible to fix
>>>>>>> with the current design of emitting debug info very early. The locati=
>>on=3D
>>>>s and target
>>>>>>> offsets of these things aren't know until later=3D2C and m3gdb really=
>> nee=3D
>>>>ds to know them.
>>>>>>>
>>>>>>>
>>>>>>> Jay K wrote:
>>>>>>>> What I meant regarding "static chain" was more like "does gcc alread=
>>y =3D
>>>>have support that we can use".
>>>>>>>> Don't any of the other languages need it already?
>>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>> =3D = 		 	   		  

From mika at async.async.caltech.edu  Fri May 21 09:44:59 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 21 May 2010 00:44:59 -0700
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl> 
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , , , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , , , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, , , ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, , , ,
	<4BF56D60.2000403@lcwb.coop>, , ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, , ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>, ,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>, ,
	<20100521053756.D74951A2094@async.async.caltech.edu>,
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>,
	<20100521064522.93AAC1A2094@async.async.caltech.edu>
	<COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
Message-ID: <20100521074459.BF5041A2061@async.async.caltech.edu>


In Modula-3 you can pass a nested function in a function call.  It can
be quite useful but it's broken in PM3 so I never use it.

I've been meaning to write an optimistic Scheme compiler that uses tricks
with nested functions passed like that to allocate closures on demand...

(With nested functions, you can essentially set up a mechanism to jump
back up the stack, of course by doubling the recursion depth, and that
you could use to copy the stack into heap memory... something like that)

    Mika

Jay K writes:
>
>Of course. I tried to read it as a teenager and got stuck on the automata s=
>tuff.
>=20
>=20
>Wirth isn't 100% clear to me.
> He describes my two schemes.
> I think he throws out the second as an unimportant optimization.
> He criticizes the first as inefficient=2C granted.
> What I don't get is the static link in addition to the dynamic link.
> Perhaps I have not accounted for recursion.
>=20
>=20
>Oh..I see..he is allowing to take the address of a nested function.
>I didn't account for that.
>I still don't understand all the arrow he draws for the static link=2C but
>I do see that my scheme doesn't suffice.
>Taking the address of a nested function..doesn't seem like a good idea.
>Maybe I'm too C-minded.
>=20
>=20
>My prototypical favorite Scheme example is:
>=20
>=20
>(define (make-adder x)
>   (define (add y) (+ x y))
>   add)
>=20
>=20
>(define add2 (make-adder 2))
>(add2 3) =3D> 5
>=20
>=20
>but Modula-3 doesn't allow for that anyway..
>=20
>Still=2C we make "closures": tuple{-1=2C function pointer=2C frame pointer}
>before calling a pointer=2C we check if it points to -1=2C and if so
>we call function pointer with frame pointer as the link.
>=20
>=20
>And then I guess=2C you might have something like this?
>=20
>=20
>=20
>int F1(int a=2C int b=2C int (*F)())
>{
>  int F2()
>  {
>    return a + b=3B
>  }
>=20
>  if (F !=3D NULL)
>   return F()=3B
>=20
>  return F1(a - 1=2C b - 1=2C &F2)=3B
>=20
>}
>=20
>=20
>F(1=2C 2=2C NULL) =3D> 3
>=20
>=20
>Though that doesn't demonstrate the generality perhaps.
>=20
>=20
>Taking the address of a nested function seems dubious.
>=20
>=20
>My "favorite" bit of Schema:
>=20
>(define (make-adder x)
>   (define (add y) (+ x y))
>   add)
>=20
>=20
>(define add2 (make-adder 2))
>=20
>(add2 3) =3D> 3
>=20
>=20
>But we don't allow that sort of thing -- frames are always stack allocated.
>=20
>=20
>=20
> - Jay
>
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Thu=2C 20 May 2010 23:45:22 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>> The Dragon Book is
>>
>> Aho=2C Sethi=2C Ullman. Compilers: Principles=2C Techniques=2C and Tools.
>> Addison-Wesley=2C 1988. Chapter 7=2C esp. Sec. 7.4.
>>
>> Mika
>>
>> Jay K writes:
>>>
>>>Thanks for the reference!
>>>=3D20
>>>search for "Good Ideas=3D2C Through the Looking Glass"
>>>finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas=
>_o=3D
>>>rigFig.pdf"
>>>(I don't need to provide the link really.)
>>>=3D20
>>> - Jay
>>>
>>>----------------------------------------
>>>> To: jay.krell at cornell.edu
>>>> Date: Thu=3D2C 20 May 2010 22:37:56 -0700
>>>> From: mika at async.async.caltech.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>
>>>>
>>>> As I recall it the "Dragon Book" has a whole section on this topic of
>>>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>>>> an expert=3D2C just remember reading it. Wirth also talks about it in h=
>is
>>>> "Good Ideas=3D2C Through the Looking Glass" (where he says the display
>>>> might be a pessimization).
>>>>
>>>> Mika
>>>>
>>>> Jay K writes:
>>>>>
>>>>>Maybe we can/should transform into one of the forms I show and dispense=
> w=3D
>>>it=3D3D
>>>>>h any gcc support?
>>>>>At the cost of losing some "easy" optimization..of nested functions?
>>>>> "easy" as in=3D3D2C occurs even without -O2=3D3D2C but might occur wit=
>h -O2?
>>>>>=3D3D20
>>>>>=3D3D20
>>>>>I know what you mean -- NT386 passes the static link in ecx.
>>>>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>>>=3D3D20
>>>>>=3D3D20
>>>>>Passing it as "just" another parameter might be less efficient=3D3D2C b=
>ut o=3D
>>>k?
>>>>> And really=3D3D2C it'd only be less efficient on one architecture -- 3=
>2bit=3D
>>> x8=3D3D
>>>>>6.
>>>>> And maybe not all x86s -- depending on if some ABIs have a register ba=
>se=3D
>>>d=3D3D
>>>>> calling convention.
>>>>>=3D3D20
>>>>>=3D3D20
>>>>>We don't need any actual ABI-compatibility with anything here=3D3D2C do=
> we?
>>>>>=3D3D20
>>>>>=3D3D20
>>>>> - Jay
>>>>>
>>>>>
>>>>>----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Thu=3D3D2C 20 May 2010 22:22:46 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>
>>>>>> That is the standard formulation=3D3D2C but different architectures h=
>ave =3D
>>>diff=3D3D
>>>>>erent optimised forms (passing static link in a register=3D3D2C etc.). =
>In a=3D
>>>ny c=3D3D
>>>>>ase=3D3D2C gcc has its own weird way of doing things=3D3D2C which we mo=
>stly u=3D
>>>se=3D3D2C =3D3D
>>>>>but from which we need a little extra support (hence the small amount o=
>f =3D
>>>sp=3D3D
>>>>>ecial tailoring).
>>>>>>
>>>>>> On 20 May 2010=3D3D2C at 21:43=3D3D2C Jay K wrote:
>>>>>>
>>>>>>>
>>>>>>> Wierd. To me the model to follow is almost obvious. It should be obv=
>io=3D
>>>us=3D3D
>>>>> to everyone and implemented the way I have in mind. :)
>>>>>>>
>>>>>>>
>>>>>>> The static link is an extra parameter.
>>>>>>> And=3D3D2C as such=3D3D2C also an extra local variable.
>>>>>>> You only need one.
>>>>>>> Each nesting level would follow another chain.
>>>>>>> Or you can pass each nesting level as an extra parameter.
>>>>>>> Or you can optimize and pass locals/parameters separately.
>>>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>>>
>>>>>>>
>>>>>>> Here=3D3D2C I worked it through:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Why doesn't it just look something like this:
>>>>>>>
>>>>>>>
>>>>>>> nested:
>>>>>>>
>>>>>>> void F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D3D a + b=3D3D3B
>>>>>>>
>>>>>>> int f2()
>>>>>>> {
>>>>>>> int d =3D3D3D a + b=3D3D3B
>>>>>>>
>>>>>>> int f3()
>>>>>>> {
>>>>>>> return d + a + c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> return a + c + f3()=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> return f2()=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> not nested:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> f1_frame_t* f1=3D3D3B
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D3D a + b=3D3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> or=3D3D2C alernatively=3D3D2C almost the same=3D3D2C pass each chain=
> as anot=3D
>>>her para=3D3D
>>>>>meter:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2=3D3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D3D2C f1)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D3D a + b=3D3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> This should be easily adapted to any function call convention/sequen=
>ce=3D
>>>.
>>>>>>> e.g. even if parameters are passed in registers.
>>>>>>>
>>>>>>>
>>>>>>> And for that matter=3D3D2C why don't we just transform it to be like=
> thi=3D
>>>s?
>>>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>>>
>>>>>>>
>>>>>>> Am I missing something?
>>>>>>>
>>>>>>>
>>>>>>> This form doesn't work?
>>>>>>>
>>>>>>>
>>>>>>> Isn't reasonably simple?
>>>>>>>
>>>>>>>
>>>>>>> Granted it might not be optimal. But it depends.
>>>>>>> You know=3D3D2C you can copy in the local/parameter values=3D3D2C bu=
>t then=3D
>>> you h=3D3D
>>>>>ave
>>>>>>> to copy them out too. You can do analysis to show they aren't change=
>d=3D
>>>=3D3D2C
>>>>>>> in which case no need to copy them out.
>>>>>>> Similarly you can pass the parameters as separate parameters=3D3D2C =
>by a=3D
>>>ddre=3D3D
>>>>>ss
>>>>>>> if they are ever changed.
>>>>>>>
>>>>>>>
>>>>>>> A portable transform couldn't depend on adjacency of locals and para=
>me=3D
>>>te=3D3D
>>>>>rs.
>>>>>>> It would have to either copy the parameters into the frame_t=3D3D2C =
>or t=3D
>>>heir=3D3D
>>>>> addresses.
>>>>>>>
>>>>>>>
>>>>>>> A portable form couldn't get the frame by taking the address of a "i=
>nd=3D
>>>iv=3D3D
>>>>>idual" local.
>>>>>>>
>>>>>>>
>>>>>>> Here is portable form:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int d=3D3D3B
>>>>>>> f1_frame_t* f1=3D3D3B
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> int c=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3D3B
>>>>>>> f.f1 =3D3D3D f1=3D3D3B
>>>>>>> f.d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3(&f)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3D3B
>>>>>>> f.a =3D3D3D a=3D3D3B
>>>>>>> f.b =3D3D3D b=3D3D3B
>>>>>>> f.c =3D3D3D a + b=3D3D3B
>>>>>>> return f2(&f)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> or:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int d=3D3D3B
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> int c=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2=3D3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3D3B
>>>>>>> f.d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3(&f=3D3D2C f1)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3D3B
>>>>>>> f.a =3D3D3D a=3D3D3B
>>>>>>> f.b =3D3D3D b=3D3D3B
>>>>>>> f.c =3D3D3D a + b=3D3D3B
>>>>>>> return f2(&f)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> Date: Thu=3D3D2C 20 May 2010 12:12:00 -0500
>>>>>>>> From: rodney_bates at lcwb.coop
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>>>
>>>>>>>> gcc even extends C with nested functions=3D3D2C and the support is =
>ther=3D
>>>e fo=3D3D
>>>>>r that. We use it too.
>>>>>>>>
>>>>>>>> Beware: The runtime model is=3D3D2C IMO=3D3D2C bizarre. Definitely =
>counte=3D
>>>rintui=3D3D
>>>>>tive and unlike anything
>>>>>>>> you will ever see elsewhere. There are two static links. One is use=
>d =3D
>>>fo=3D3D
>>>>>r the first step
>>>>>>>> in following a static chain and points to the expected place in the=
> t=3D
>>>ar=3D3D
>>>>>get frame. The other
>>>>>>>> is used of subsequent steps in chain-following=3D3D2C and points to=
> som=3D
>>>ewhe=3D3D
>>>>>re inside the target
>>>>>>>> frame that is dependent on the target procedure. It's the beginning=
> o=3D
>>>f =3D3D
>>>>>a subrecord where
>>>>>>>> all the nonlocally-referenced variables are collected. The second s=
>ta=3D
>>>ti=3D3D
>>>>>c link is also
>>>>>>>> located in there. All the nonlocally-referenced variables and param=
>et=3D
>>>er=3D3D
>>>>>s are duplicated
>>>>>>>> in there too.
>>>>>>>>
>>>>>>>> I'm not sure I remembered these details exactly right. Maybe both l=
>in=3D
>>>ks=3D3D
>>>>> point to the
>>>>>>>> subrecord=3D3D2C but one is located at a traditional procedure-inde=
>pend=3D
>>>ent=3D3D
>>>>>=3D3D2C fixed location
>>>>>>>> in the frame=3D3D2C while the second is located in the subrecord. A=
>lso=3D
>>>=3D3D2C s=3D3D
>>>>>ometimes the first
>>>>>>>> static link value is kept in a register and never stored.
>>>>>>>>
>>>>>>>> What this all apparently accomplishes is simplifying an "insanely c=
>om=3D
>>>pl=3D3D
>>>>>icated" _compile-time_
>>>>>>>> scheme that=3D3D2C I believe came from interaction between nested p=
>roce=3D
>>>dure=3D3D
>>>>>s and inlining them.
>>>>>>>>
>>>>>>>> But it's at the cost of what I would call an insanely complicated _=
>ru=3D
>>>nt=3D3D
>>>>>ime_ scheme.
>>>>>>>>
>>>>>>>> It undermined m3gdb's handling of static links=3D3D2C and I don't t=
>hink=3D
>>> it'=3D3D
>>>>>s possible to fix
>>>>>>>> with the current design of emitting debug info very early. The loca=
>ti=3D
>>>on=3D3D
>>>>>s and target
>>>>>>>> offsets of these things aren't know until later=3D3D2C and m3gdb re=
>ally=3D
>>> nee=3D3D
>>>>>ds to know them.
>>>>>>>>
>>>>>>>>
>>>>>>>> Jay K wrote:
>>>>>>>>> What I meant regarding "static chain" was more like "does gcc alre=
>ad=3D
>>>y =3D3D
>>>>>have support that we can use".
>>>>>>>>> Don't any of the other languages need it already?
>>>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>> =3D3D =3D 		 	   		  =


From hendrik at topoi.pooq.com  Fri May 21 08:59:09 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 21 May 2010 02:59:09 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
References: <20100521064522.93AAC1A2094@async.async.caltech.edu>
	<COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
Message-ID: <20100521065909.GA27981@topoi.pooq.com>

On Fri, May 21, 2010 at 07:41:46AM +0000, Jay K wrote:
> 
> Oh..I see..he is allowing to take the address of a nested function.
> I didn't account for that.
> I still don't understand all the arrow he draws for the static link, but
> I do see that my scheme doesn't suffice.
> Taking the address of a nested function..doesn't seem like a good idea.

Works fine as long as you only use it within other nested stuff.  Very 
useful.  It's the way call-by-name in Algol 60 was implemented.  And if 
you were to put the stack on the heap and garbage-collect it (which 
can cost a lot (Scheme does this, not recommended for Modula 3)), you 
don't need the nesting restriction.

> Maybe I'm too C-minded.

-- hendrik



From jay.krell at cornell.edu  Fri May 21 14:54:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 12:54:35 +0000
Subject: [M3devel] RC5?
Message-ID: <COL101-W38D3ADE3E3D08C7CDE0549E6E40@phx.gbl>


RC5 packages have been here a month: http://www.opencm3.net/releng/download.html

Any users?

?- Jay





 		 	   		  

From hosking at cs.purdue.edu  Fri May 21 19:08:02 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 21 May 2010 13:08:02 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , , , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , , , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, , , ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, , , ,
	<4BF56D60.2000403@lcwb.coop>, , ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, , ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>, ,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>, ,
	<20100521053756.D74951A2094@async.async.caltech.edu>,
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>,
	<20100521064522.93AAC1A2094@async.async.caltech.edu>
	<COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
Message-ID: <A5424DAE-BAB3-456A-B059-82FAF82EE986@cs.purdue.edu>

We don't want to bypass the gcc support.
It works well with register allocation, etc.


On 21 May 2010, at 03:41, Jay K wrote:

> 
> Of course. I tried to read it as a teenager and got stuck on the automata stuff.
> 
> 
> Wirth isn't 100% clear to me.
> He describes my two schemes.
> I think he throws out the second as an unimportant optimization.
> He criticizes the first as inefficient, granted.
> What I don't get is the static link in addition to the dynamic link.
> Perhaps I have not accounted for recursion.
> 
> 
> Oh..I see..he is allowing to take the address of a nested function.
> I didn't account for that.
> I still don't understand all the arrow he draws for the static link, but
> I do see that my scheme doesn't suffice.
> Taking the address of a nested function..doesn't seem like a good idea.
> Maybe I'm too C-minded.
> 
> 
> My prototypical favorite Scheme example is:
> 
> 
> (define (make-adder x)
>   (define (add y) (+ x y))
>   add)
> 
> 
> (define add2 (make-adder 2))
> (add2 3) => 5
> 
> 
> but Modula-3 doesn't allow for that anyway..
> 
> Still, we make "closures": tuple{-1, function pointer, frame pointer}
> before calling a pointer, we check if it points to -1, and if so
> we call function pointer with frame pointer as the link.
> 
> 
> And then I guess, you might have something like this?
> 
> 
> 
> int F1(int a, int b, int (*F)())
> {
>  int F2()
>  {
>    return a + b;
>  }
> 
>  if (F != NULL)
>   return F();
> 
>  return F1(a - 1, b - 1, &F2);
> 
> }
> 
> 
> F(1, 2, NULL) => 3
> 
> 
> Though that doesn't demonstrate the generality perhaps.
> 
> 
> Taking the address of a nested function seems dubious.
> 
> 
> My "favorite" bit of Schema:
> 
> (define (make-adder x)
>   (define (add y) (+ x y))
>   add)
> 
> 
> (define add2 (make-adder 2))
> 
> (add2 3) => 3
> 
> 
> But we don't allow that sort of thing -- frames are always stack allocated.
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Thu, 20 May 2010 23:45:22 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> The Dragon Book is
>> 
>> Aho, Sethi, Ullman. Compilers: Principles, Techniques, and Tools.
>> Addison-Wesley, 1988. Chapter 7, esp. Sec. 7.4.
>> 
>> Mika
>> 
>> Jay K writes:
>>> 
>>> Thanks for the reference!
>>> =20
>>> search for "Good Ideas=2C Through the Looking Glass"
>>> finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_o=
>>> rigFig.pdf"
>>> (I don't need to provide the link really.)
>>> =20
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> To: jay.krell at cornell.edu
>>>> Date: Thu=2C 20 May 2010 22:37:56 -0700
>>>> From: mika at async.async.caltech.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>> 
>>>> 
>>>> As I recall it the "Dragon Book" has a whole section on this topic of
>>>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>>>> an expert=2C just remember reading it. Wirth also talks about it in his
>>>> "Good Ideas=2C Through the Looking Glass" (where he says the display
>>>> might be a pessimization).
>>>> 
>>>> Mika
>>>> 
>>>> Jay K writes:
>>>>> 
>>>>> Maybe we can/should transform into one of the forms I show and dispense w=
>>> it=3D
>>>>> h any gcc support?
>>>>> At the cost of losing some "easy" optimization..of nested functions?
>>>>> "easy" as in=3D2C occurs even without -O2=3D2C but might occur with -O2?
>>>>> =3D20
>>>>> =3D20
>>>>> I know what you mean -- NT386 passes the static link in ecx.
>>>>> This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>>> =3D20
>>>>> =3D20
>>>>> Passing it as "just" another parameter might be less efficient=3D2C but o=
>>> k?
>>>>> And really=3D2C it'd only be less efficient on one architecture -- 32bit=
>>> x8=3D
>>>>> 6.
>>>>> And maybe not all x86s -- depending on if some ABIs have a register base=
>>> d=3D
>>>>> calling convention.
>>>>> =3D20
>>>>> =3D20
>>>>> We don't need any actual ABI-compatibility with anything here=3D2C do we?
>>>>> =3D20
>>>>> =3D20
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Thu=3D2C 20 May 2010 22:22:46 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>> 
>>>>>> That is the standard formulation=3D2C but different architectures have =
>>> diff=3D
>>>>> erent optimised forms (passing static link in a register=3D2C etc.). In a=
>>> ny c=3D
>>>>> ase=3D2C gcc has its own weird way of doing things=3D2C which we mostly u=
>>> se=3D2C =3D
>>>>> but from which we need a little extra support (hence the small amount of =
>>> sp=3D
>>>>> ecial tailoring).
>>>>>> 
>>>>>> On 20 May 2010=3D2C at 21:43=3D2C Jay K wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Wierd. To me the model to follow is almost obvious. It should be obvio=
>>> us=3D
>>>>> to everyone and implemented the way I have in mind. :)
>>>>>>> 
>>>>>>> 
>>>>>>> The static link is an extra parameter.
>>>>>>> And=3D2C as such=3D2C also an extra local variable.
>>>>>>> You only need one.
>>>>>>> Each nesting level would follow another chain.
>>>>>>> Or you can pass each nesting level as an extra parameter.
>>>>>>> Or you can optimize and pass locals/parameters separately.
>>>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>>> 
>>>>>>> 
>>>>>>> Here=3D2C I worked it through:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Why doesn't it just look something like this:
>>>>>>> 
>>>>>>> 
>>>>>>> nested:
>>>>>>> 
>>>>>>> void F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D a + b=3D3B
>>>>>>> 
>>>>>>> int f2()
>>>>>>> {
>>>>>>> int d =3D3D a + b=3D3B
>>>>>>> 
>>>>>>> int f3()
>>>>>>> {
>>>>>>> return d + a + c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> return a + c + f3()=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> return f2()=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> not nested:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> f1_frame_t* f1=3D3B
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D a + b=3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> or=3D2C alernatively=3D2C almost the same=3D2C pass each chain as anot=
>>> her para=3D
>>>>> meter:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D2C f1)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D a + b=3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> This should be easily adapted to any function call convention/sequence=
>>> .
>>>>>>> e.g. even if parameters are passed in registers.
>>>>>>> 
>>>>>>> 
>>>>>>> And for that matter=3D2C why don't we just transform it to be like thi=
>>> s?
>>>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>>> 
>>>>>>> 
>>>>>>> Am I missing something?
>>>>>>> 
>>>>>>> 
>>>>>>> This form doesn't work?
>>>>>>> 
>>>>>>> 
>>>>>>> Isn't reasonably simple?
>>>>>>> 
>>>>>>> 
>>>>>>> Granted it might not be optimal. But it depends.
>>>>>>> You know=3D2C you can copy in the local/parameter values=3D2C but then=
>>> you h=3D
>>>>> ave
>>>>>>> to copy them out too. You can do analysis to show they aren't changed=
>>> =3D2C
>>>>>>> in which case no need to copy them out.
>>>>>>> Similarly you can pass the parameters as separate parameters=3D2C by a=
>>> ddre=3D
>>>>> ss
>>>>>>> if they are ever changed.
>>>>>>> 
>>>>>>> 
>>>>>>> A portable transform couldn't depend on adjacency of locals and parame=
>>> te=3D
>>>>> rs.
>>>>>>> It would have to either copy the parameters into the frame_t=3D2C or t=
>>> heir=3D
>>>>> addresses.
>>>>>>> 
>>>>>>> 
>>>>>>> A portable form couldn't get the frame by taking the address of a "ind=
>>> iv=3D
>>>>> idual" local.
>>>>>>> 
>>>>>>> 
>>>>>>> Here is portable form:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int d=3D3B
>>>>>>> f1_frame_t* f1=3D3B
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> int c=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3B
>>>>>>> f.f1 =3D3D f1=3D3B
>>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3(&f)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3B
>>>>>>> f.a =3D3D a=3D3B
>>>>>>> f.b =3D3D b=3D3B
>>>>>>> f.c =3D3D a + b=3D3B
>>>>>>> return f2(&f)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> or:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int d=3D3B
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> int c=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3B
>>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3(&f=3D2C f1)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3B
>>>>>>> f.a =3D3D a=3D3B
>>>>>>> f.b =3D3D b=3D3B
>>>>>>> f.c =3D3D a + b=3D3B
>>>>>>> return f2(&f)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> Date: Thu=3D2C 20 May 2010 12:12:00 -0500
>>>>>>>> From: rodney_bates at lcwb.coop
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>>> 
>>>>>>>> gcc even extends C with nested functions=3D2C and the support is ther=
>>> e fo=3D
>>>>> r that. We use it too.
>>>>>>>> 
>>>>>>>> Beware: The runtime model is=3D2C IMO=3D2C bizarre. Definitely counte=
>>> rintui=3D
>>>>> tive and unlike anything
>>>>>>>> you will ever see elsewhere. There are two static links. One is used =
>>> fo=3D
>>>>> r the first step
>>>>>>>> in following a static chain and points to the expected place in the t=
>>> ar=3D
>>>>> get frame. The other
>>>>>>>> is used of subsequent steps in chain-following=3D2C and points to som=
>>> ewhe=3D
>>>>> re inside the target
>>>>>>>> frame that is dependent on the target procedure. It's the beginning o=
>>> f =3D
>>>>> a subrecord where
>>>>>>>> all the nonlocally-referenced variables are collected. The second sta=
>>> ti=3D
>>>>> c link is also
>>>>>>>> located in there. All the nonlocally-referenced variables and paramet=
>>> er=3D
>>>>> s are duplicated
>>>>>>>> in there too.
>>>>>>>> 
>>>>>>>> I'm not sure I remembered these details exactly right. Maybe both lin=
>>> ks=3D
>>>>> point to the
>>>>>>>> subrecord=3D2C but one is located at a traditional procedure-independ=
>>> ent=3D
>>>>> =3D2C fixed location
>>>>>>>> in the frame=3D2C while the second is located in the subrecord. Also=
>>> =3D2C s=3D
>>>>> ometimes the first
>>>>>>>> static link value is kept in a register and never stored.
>>>>>>>> 
>>>>>>>> What this all apparently accomplishes is simplifying an "insanely com=
>>> pl=3D
>>>>> icated" _compile-time_
>>>>>>>> scheme that=3D2C I believe came from interaction between nested proce=
>>> dure=3D
>>>>> s and inlining them.
>>>>>>>> 
>>>>>>>> But it's at the cost of what I would call an insanely complicated _ru=
>>> nt=3D
>>>>> ime_ scheme.
>>>>>>>> 
>>>>>>>> It undermined m3gdb's handling of static links=3D2C and I don't think=
>>> it'=3D
>>>>> s possible to fix
>>>>>>>> with the current design of emitting debug info very early. The locati=
>>> on=3D
>>>>> s and target
>>>>>>>> offsets of these things aren't know until later=3D2C and m3gdb really=
>>> nee=3D
>>>>> ds to know them.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Jay K wrote:
>>>>>>>>> What I meant regarding "static chain" was more like "does gcc alread=
>>> y =3D
>>>>> have support that we can use".
>>>>>>>>> Don't any of the other languages need it already?
>>>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>>> 
>>>>>>>>> - Jay
>>>>>>>>> 
>>>>>> =3D = 		 	   		  



From rodney_bates at lcwb.coop  Fri May 21 21:45:32 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 21 May 2010 14:45:32 -0500
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	<4BF56D60.2000403@lcwb.coop>
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
Message-ID: <4BF6E2DC.3090601@lcwb.coop>

I have no quarrels with you there, Jay.  I'm not advocating it, just
reporting what I know about how gcc does it.

Jay K wrote:
> Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
>  
>  
> The static link is an extra parameter.
> And, as such, also an extra local variable.
> You only need one.
> Each nesting level would follow another chain.
> Or you can pass each nesting level as an extra parameter.
> Or you can optimize and pass locals/parameters separately.
> But there is an obvious straightforward non-optimized form. ?
>  
>  
> Here, I worked it through:
>  
>  
>  
> Why doesn't it just look something like this:
>  
>  
> nested:
>  
> void F1(int a, int b)
> {
>   int c = a + b;
>  
>   int f2()
>   {
>     int d = a + b;
>  
>     int f3()
>     {
>        return d + a + c;
>     }
>  
>     return a + c + f3();
>   }
>  
>   return f2();
> }
>  
> not nested:
>  
> 
> typedef struct {
>   /* locals */
>   int d;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
>   f1_frame_t* f1;
> } f2_frame_t;
>  
> 
> typedef struct {
>   /* locals */
>   int c;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
>   int a;
>   int b;
> } f1_frame_t;
>  
>  
> int f3(f2_frame_t* f2)
> {
>     return f2->d + f2->f1->a + f2->f1->c;
> }
>  
> 
> int f2(f1_frame_t* f1)
> {
>   int d = f1->a + f1->b;
>   return f1->a + f1->c + f3((f2_frame_t*)&d);
> }
>  
> 
> int F1(int a, int b)
> {
>   int c = a + b;
>   return f2((f1_frame_t*)&c);
> }
> 
>  
> or, alernatively, almost the same, pass each chain as another parameter:
>  
> 
> typedef struct {
>   /* locals */
>   int d;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
> } f2_frame_t;
>  
> 
> typedef struct {
>   /* locals */
>   int c;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
>   int a;
>   int b;
> } f1_frame_t;
>  
>  
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>     return f2->d + f1->a + f1->c;
> }
>  
>  
> 
> int f2(f1_frame_t* f1)
> {
>   int d = f1->a + f1->b;
>   return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
> }
>  
> 
> int F1(int a, int b)
> {
>   int c = a + b;
>   return f2((f1_frame_t*)&c);
> }
>  
>  
> This should be easily adapted to any function call convention/sequence.
> e.g. even if parameters are passed in registers.
>  
>  
> And for that matter, why don't we just transform it to be like this?
>   With the goal of reducing/eliminating gcc patches?
>  
>  
> Am I missing something?
>  
> 
> This form doesn't work?
>  
> 
> Isn't reasonably simple?
>  
> 
> Granted it might not be optimal. But it depends.
>   You know, you can copy in the local/parameter values, but then you have
>    to copy them out too. You can do analysis to show they aren't changed,
>    in which case no need to copy them out.
>   Similarly you can pass the parameters as separate parameters, by address
>    if they are ever changed.
> 
>  
> A portable transform couldn't depend on adjacency of locals and parameters.
> It would have to either copy the parameters into the frame_t, or their addresses.
>  
>  
> A portable form couldn't get the frame by taking the address of a "individual" local.
>  
>  
> Here is portable form:
>  
>  
> typedef struct {
>   int d;
>   f1_frame_t* f1;
> } f2_frame_t;
>  
> typedef struct {
>   int a;
>   int b;
>   int c;
> } f1_frame_t;
>  
> 
> int f3(f2_frame_t* f2)
> {
>     return f2->d + f2->f1->a + f2->f1->c;
> }
>  
> int f2(f1_frame_t* f1)
> {
>   f2_frame_t f;
>   f.f1 = f1;
>   f.d = f1->a + f1->b;
>   return f1->a + f1->c + f3(&f);
> }
>  
>  
> int F1(int a, int b)
> {
>   f1_frame_t f;
>   f.a = a;
>   f.b = b;
>   f.c = a + b;
>   return f2(&f);
> }
>  
>  
> or:
>  
>  
> typedef struct {
>   int d;
> } f2_frame_t;
>  
>  
> typedef struct {
>   int a;
>   int b;
>   int c;
> } f1_frame_t;
>  
>  
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>     return f2->d + f1->a + f1->c;
> }
>  
>  
> int f2(f1_frame_t* f1)
> {
>   f2_frame_t f;
>   f.d = f1->a + f1->b;
>   return f1->a + f1->c + f3(&f, f1);
> }
> 
>  
> int F1(int a, int b)
> {
>   f1_frame_t f;
>   f.a = a;
>   f.b = b;
>   f.c = a + b;
>   return f2(&f);
> }
> 
>  
>  
>  
>  - Jay
> 
> 
> 
> ----------------------------------------
>> Date: Thu, 20 May 2010 12:12:00 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>> gcc even extends C with nested functions, and the support is there for that. We use it too.
>>
>> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
>> you will ever see elsewhere. There are two static links. One is used for the first step
>> in following a static chain and points to the expected place in the target frame. The other
>> is used of subsequent steps in chain-following, and points to somewhere inside the target
>> frame that is dependent on the target procedure. It's the beginning of a subrecord where
>> all the nonlocally-referenced variables are collected. The second static link is also
>> located in there. All the nonlocally-referenced variables and parameters are duplicated
>> in there too.
>>
>> I'm not sure I remembered these details exactly right. Maybe both links point to the
>> subrecord, but one is located at a traditional procedure-independent, fixed location
>> in the frame, while the second is located in the subrecord. Also, sometimes the first
>> static link value is kept in a register and never stored.
>>
>> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
>> scheme that, I believe came from interaction between nested procedures and inlining them.
>>
>> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>>
>> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
>> with the current design of emitting debug info very early. The locations and target
>> offsets of these things aren't know until later, and m3gdb really needs to know them.
>>
>>
>> Jay K wrote:
>>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>>> Don't any of the other languages need it already?
>>> Ada? Pascal? Maybe the nested C function support?
>>>
>>> - Jay
>>> 		 	   		  


From mika at async.async.caltech.edu  Sat May 22 23:53:17 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 22 May 2010 14:53:17 -0700
Subject: [M3devel] OS for CM3
Message-ID: <20100522215317.E428D1A2096@async.async.caltech.edu>

Hi Modula-3ers,

Can anyone give me some advice on what OS to install on a new PC compute
server with 16 to 24 cores and 16 to 32 GB of RAM?  The code I'm going
to be running is all written in Modula-3 with some C and Fortran thrown
in and I want to use CM3.  The odd extra thing in Java and some analysis
in R.  Currently I'm stuck with PM3 on FreeBSD/i386.

I've always liked the ease of administration (i.e., I'm an old dog and I
don't have to learn anything new) of FreeBSD, but the threading support
seems much better with Linux?  I do really want to run multi-threaded
programs across several CPUs.

I am considering Debian/amd64.  Any other recommendations, experiences?

    Mika


From dragisha at m3w.org  Sun May 23 00:32:25 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 23 May 2010 00:32:25 +0200
Subject: [M3devel] OS for CM3
In-Reply-To: <20100522215317.E428D1A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
Message-ID: <1274567545.29716.4.camel@localhost>

There is no simple nor unique answer to this. I prefer Fedora, and I've
been using RedHat since 1996... Some people prefer RHEL, or CentOS if
they like it freer. Jumped of SLS then Slackware I've been using from
1993-1995, and never looked back.

Easy to administer and maintain, most of modern distros have GUI for
every admin task.

On Sat, 2010-05-22 at 14:53 -0700, Mika Nystrom wrote:
> Hi Modula-3ers,
> 
> Can anyone give me some advice on what OS to install on a new PC compute
> server with 16 to 24 cores and 16 to 32 GB of RAM?  The code I'm going
> to be running is all written in Modula-3 with some C and Fortran thrown
> in and I want to use CM3.  The odd extra thing in Java and some analysis
> in R.  Currently I'm stuck with PM3 on FreeBSD/i386.
> 
> I've always liked the ease of administration (i.e., I'm an old dog and I
> don't have to learn anything new) of FreeBSD, but the threading support
> seems much better with Linux?  I do really want to run multi-threaded
> programs across several CPUs.
> 
> I am considering Debian/amd64.  Any other recommendations, experiences?
> 
>     Mika

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



From jay.krell at cornell.edu  Sun May 23 01:35:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 22 May 2010 23:35:52 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <1274567545.29716.4.camel@localhost>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
Message-ID: <COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl>


Modula-3 will run on almost anything. Install something we don't work on yet and give me ssh access. :)
Like get a Loongson laptop -- comes with Linux/MIPS but can also run OpenBSD and maybe others.
Or, install something we don't have yet in Hudson yet, e.g. NetBSD/amd64, and have Olaf add jobs for it.

Seriously, for Hudson purposes, NetBSD/amd64 is probably the best, followed by NetBSD/x86.
I'll set these up eventually.


Regarding Linux, I've been using Debian, because it has about the best support for multiple architectures.
? And then the same "experience" across all of them -- same installer and package management.


Gentoo would be the next or previous choice -- not clear what the ppc64 support is in Debian.
It helps that I first used wimpy Ubuntu before moving up to the supposedly manly Debian.
Gentoo I've had trouble getting to install+boot.


OpenBSD has about the best install experience imho and a certain hard to capture purity about it.
? Examples:
???? NetBSD and FreeBSD support powerpc.
???? FreeBSD's partitioner doesn't run on powerpc though.
???? NetBSD I couldn't get to install.
???? OpenBSD was easy.
?? 
???? Attempting to install Linux or NetBSD on an SGI machine apparently killed the machine.
???? I couldn't get either to install or boot. One of them might not have local console working.
???? But again OpenBSD was easy and worked.


??? My OpenBSD/sgimips CD was actually bad. But it worked enough to boot, and the
??? the install was then easy to fallback to over the network.


But they don't have kernel threads, so, while we work, we probably scale the worst here.
? Besides, user threads are an /option/ on all Posix systems, only /required/ on OpenBSD.


I think all the user interfaces are terrible though.
I am most productive by far on NT, using find-in-files countless times daily in Visual C++ 5.0.
?It is so much better than command line grep, and it beats every other IDE/editor I have tried,
?and I have tried many. Komodo Edit is so-so. MonoDevelop was promising, but it refused
?to open *.m3 files as plain text. TextWrangler on Mac is so-so, what I use for lack
?of anything good. Eclipse is confusing to install and I don't think worked well, but I forget.


Mac is distant second in productivity.
? At least I don't have to constantly flip the newlines and it has a fast fork.


Everything else I can't even edit files on. I can't copy/paste, navigate quickly (e.g. esp. using
page up/down/home/end/mouse!). NT also has a fast console with half decent most support.


My most productive pattern is editing on NT and copying files around otherwise.


As well, consider that the NT Modula-3 backend is unique and pretty darn good.
? It is fast, in-proc, and always optimizes a certain amount.
? In its only mode, it generates significantly better code than unoptimizing gcc.


?Compiling N files on NT takes one process to compile, codegen, write objs files,
and then another one or two to link.


Compiling N files on the other systems takes one process to compile, N runs
of m3cg to generate N asssembly files, N runs to run the assembler.


If you really need an *occasional* Posixy experience on NT, there is Cygwin and SFU/SUA.
Cygwin has a very slow fork and it is very noticable.
SFU/SUA has a "normally" fast fork, and it is very noticable.


FreeBSD, Solaris, NetBSD, Linux -- should all be about the same.
?(ok, Solaris/x86 support is only in head, not release).


Then there are the non-x86 ones, like HP-UX, OSF/1, Irix, AIX, VMS... :)


Also, for Hudson purposes, we need Java.
That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
Linux now has good enough Java on all architectures.
? There was a project to eliminate all the assembly code. And we have no problem
??? e.g. now on Linux/sparc and Linux/powerpc.

All the commercial systems probably suffice also.

?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: mika at async.async.caltech.edu
> Date: Sun, 23 May 2010 00:32:25 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] OS for CM3
>
> There is no simple nor unique answer to this. I prefer Fedora, and I've
> been using RedHat since 1996... Some people prefer RHEL, or CentOS if
> they like it freer. Jumped of SLS then Slackware I've been using from
> 1993-1995, and never looked back.
>
> Easy to administer and maintain, most of modern distros have GUI for
> every admin task.
>
> On Sat, 2010-05-22 at 14:53 -0700, Mika Nystrom wrote:
>> Hi Modula-3ers,
>>
>> Can anyone give me some advice on what OS to install on a new PC compute
>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
>> to be running is all written in Modula-3 with some C and Fortran thrown
>> in and I want to use CM3. The odd extra thing in Java and some analysis
>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
>>
>> I've always liked the ease of administration (i.e., I'm an old dog and I
>> don't have to learn anything new) of FreeBSD, but the threading support
>> seems much better with Linux? I do really want to run multi-threaded
>> programs across several CPUs.
>>
>> I am considering Debian/amd64. Any other recommendations, experiences?
>>
>> Mika
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Sun May 23 01:40:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 22 May 2010 23:40:46 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <1274567545.29716.4.camel@localhost>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
Message-ID: <COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>


ps: Slackware was fine back when I used it. RedHat is ok, but it at least used to take forever to do any package management compared to Ubuntu/Debian.
Suse has/had RedHat's problem, also being rpm basedi but also seemed to lead in gui/managability.


Anyway, other than Mac and NT, all my other systems are now ssh command line and impossible to do much with. :)


ps: I also like *BSD due to the reduced number of choices, and the "integrated build", where you can build a bit
more in one nice go, not just the kernel. Linux is so darn chaotic.
But I rarely take any advantage of this.
I would really like, whatever I run, to build the entire thing from source, and do it fairly easily.
?Have the whole thing be debuggable.
?Cross building support would be nice too, though lately people seem to give up and use qemu.
? Too much building stuff wants to run as it builds, like using autoconf.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org; mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] OS for CM3
> Date: Sat, 22 May 2010 23:35:52 +0000
>
>
> Modula-3 will run on almost anything. Install something we don't work on yet and give me ssh access. :)
> Like get a Loongson laptop -- comes with Linux/MIPS but can also run OpenBSD and maybe others.
> Or, install something we don't have yet in Hudson yet, e.g. NetBSD/amd64, and have Olaf add jobs for it.
>
> Seriously, for Hudson purposes, NetBSD/amd64 is probably the best, followed by NetBSD/x86.
> I'll set these up eventually.
>
>
> Regarding Linux, I've been using Debian, because it has about the best support for multiple architectures.
>   And then the same "experience" across all of them -- same installer and package management.
>
>
> Gentoo would be the next or previous choice -- not clear what the ppc64 support is in Debian.
> It helps that I first used wimpy Ubuntu before moving up to the supposedly manly Debian.
> Gentoo I've had trouble getting to install+boot.
>
>
> OpenBSD has about the best install experience imho and a certain hard to capture purity about it.
>   Examples:
>      NetBSD and FreeBSD support powerpc.
>      FreeBSD's partitioner doesn't run on powerpc though.
>      NetBSD I couldn't get to install.
>      OpenBSD was easy.
>
>      Attempting to install Linux or NetBSD on an SGI machine apparently killed the machine.
>      I couldn't get either to install or boot. One of them might not have local console working.
>      But again OpenBSD was easy and worked.
>
>
>     My OpenBSD/sgimips CD was actually bad. But it worked enough to boot, and the
>     the install was then easy to fallback to over the network.
>
>
> But they don't have kernel threads, so, while we work, we probably scale the worst here.
>   Besides, user threads are an /option/ on all Posix systems, only /required/ on OpenBSD.
>
>
> I think all the user interfaces are terrible though.
> I am most productive by far on NT, using find-in-files countless times daily in Visual C++ 5.0.
>  It is so much better than command line grep, and it beats every other IDE/editor I have tried,
>  and I have tried many. Komodo Edit is so-so. MonoDevelop was promising, but it refused
>  to open *.m3 files as plain text. TextWrangler on Mac is so-so, what I use for lack
>  of anything good. Eclipse is confusing to install and I don't think worked well, but I forget.
>
>
> Mac is distant second in productivity.
>   At least I don't have to constantly flip the newlines and it has a fast fork.
>
>
> Everything else I can't even edit files on. I can't copy/paste, navigate quickly (e.g. esp. using
> page up/down/home/end/mouse!). NT also has a fast console with half decent most support.
>
>
> My most productive pattern is editing on NT and copying files around otherwise.
>
>
> As well, consider that the NT Modula-3 backend is unique and pretty darn good.
>   It is fast, in-proc, and always optimizes a certain amount.
>   In its only mode, it generates significantly better code than unoptimizing gcc.
>
>
>  Compiling N files on NT takes one process to compile, codegen, write objs files,
> and then another one or two to link.
>
>
> Compiling N files on the other systems takes one process to compile, N runs
> of m3cg to generate N asssembly files, N runs to run the assembler.
>
>
> If you really need an *occasional* Posixy experience on NT, there is Cygwin and SFU/SUA.
> Cygwin has a very slow fork and it is very noticable.
> SFU/SUA has a "normally" fast fork, and it is very noticable.
>
>
> FreeBSD, Solaris, NetBSD, Linux -- should all be about the same.
>  (ok, Solaris/x86 support is only in head, not release).
>
>
> Then there are the non-x86 ones, like HP-UX, OSF/1, Irix, AIX, VMS... :)
>
>
> Also, for Hudson purposes, we need Java.
> That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
> Linux now has good enough Java on all architectures.
>   There was a project to eliminate all the assembly code. And we have no problem
>     e.g. now on Linux/sparc and Linux/powerpc.
>
> All the commercial systems probably suffice also.
>
>  - Jay
>
> ----------------------------------------
>> From: dragisha at m3w.org
>> To: mika at async.async.caltech.edu
>> Date: Sun, 23 May 2010 00:32:25 +0200
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] OS for CM3
>>
>> There is no simple nor unique answer to this. I prefer Fedora, and I've
>> been using RedHat since 1996... Some people prefer RHEL, or CentOS if
>> they like it freer. Jumped of SLS then Slackware I've been using from
>> 1993-1995, and never looked back.
>>
>> Easy to administer and maintain, most of modern distros have GUI for
>> every admin task.
>>
>> On Sat, 2010-05-22 at 14:53 -0700, Mika Nystrom wrote:
>>> Hi Modula-3ers,
>>>
>>> Can anyone give me some advice on what OS to install on a new PC compute
>>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
>>> to be running is all written in Modula-3 with some C and Fortran thrown
>>> in and I want to use CM3. The odd extra thing in Java and some analysis
>>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
>>>
>>> I've always liked the ease of administration (i.e., I'm an old dog and I
>>> don't have to learn anything new) of FreeBSD, but the threading support
>>> seems much better with Linux? I do really want to run multi-threaded
>>> programs across several CPUs.
>>>
>>> I am considering Debian/amd64. Any other recommendations, experiences?
>>>
>>> Mika
>>
>> --
>> Dragi?a Duri?
>>
>
 		 	   		  

From mika at async.async.caltech.edu  Sun May 23 02:08:49 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 22 May 2010 17:08:49 -0700
Subject: [M3devel] OS for CM3
In-Reply-To: <COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl> 
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
	<COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>
Message-ID: <20100523000849.BA8E61A2096@async.async.caltech.edu>

Well I know all about the various OS tradeoffs, I was asking more
about Modula-3 itself.

I want to use kernel threads, so I can share large data structures 
across CPUs.  This is for production work, not a development platform.
My main development platform will probably stay FreeBSD/i386 for a while.

Yes I agree Linux is chaotic.  But I can't stand Windows, because I
hate GUIs (because I can't automate them and my philosophy is to make
the computer work for me, not the other way around).  I know all the
old-fashioned Unix admin commands by heart (I am somewhat dismayed
that the old kill -1 convention for making daemons re-read their config
files seems to have fallen by the wayside!)  My .twmrc is dated 1992.
And PageUp etc work fine in emacs for me :-)

In other words the system will just have command-line access.  In
fact it's supposed to sit in a locked machine room.

Err, to the point... maybe it got lost in the vague generality of the
question.  

My real question is: do kernel threads work on *BSD at all?

I haven't done a proper back to back test but the Debian system
"seems faster" than FreeBSD, running on the same amd64 hardware.

Or perhaps.. crazy question.. can one make a hackintosh/amd64 out of a
16-core machine?

I seem to remember Tony made some (bad) comments about FreeBSD kernel
threads a few months ago...

    Mika

Jay K writes:
>
>ps: Slackware was fine back when I used it. RedHat is ok=2C but it at least=
> used to take forever to do any package management compared to Ubuntu/Debia=
>n.
>Suse has/had RedHat's problem=2C also being rpm basedi but also seemed to l=
>ead in gui/managability.
>
>
>Anyway=2C other than Mac and NT=2C all my other systems are now ssh command=
> line and impossible to do much with. :)
>
>
>ps: I also like *BSD due to the reduced number of choices=2C and the "integ=
>rated build"=2C where you can build a bit
>more in one nice go=2C not just the kernel. Linux is so darn chaotic.
>But I rarely take any advantage of this.
>I would really like=2C whatever I run=2C to build the entire thing from sou=
>rce=2C and do it fairly easily.
>=A0Have the whole thing be debuggable.
>=A0Cross building support would be nice too=2C though lately people seem to=
> give up and use qemu.
>=A0 Too much building stuff wants to run as it builds=2C like using autocon=
>f.
>
>
>=A0- Jay
>
>----------------------------------------
>> From: jay.krell at cornell.edu
>> To: dragisha at m3w.org=3B mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] OS for CM3
>> Date: Sat=2C 22 May 2010 23:35:52 +0000
>>
>>
>> Modula-3 will run on almost anything. Install something we don't work on =
>yet and give me ssh access. :)
>> Like get a Loongson laptop -- comes with Linux/MIPS but can also run Open=
>BSD and maybe others.
>> Or=2C install something we don't have yet in Hudson yet=2C e.g. NetBSD/am=
>d64=2C and have Olaf add jobs for it.
>>
>> Seriously=2C for Hudson purposes=2C NetBSD/amd64 is probably the best=2C =
>followed by NetBSD/x86.
>> I'll set these up eventually.
>>
>>
>> Regarding Linux=2C I've been using Debian=2C because it has about the bes=
>t support for multiple architectures.
>>   And then the same "experience" across all of them -- same installer and=
> package management.
>>
>>
>> Gentoo would be the next or previous choice -- not clear what the ppc64 s=
>upport is in Debian.
>> It helps that I first used wimpy Ubuntu before moving up to the supposedl=
>y manly Debian.
>> Gentoo I've had trouble getting to install+boot.
>>
>>
>> OpenBSD has about the best install experience imho and a certain hard to =
>capture purity about it.
>>   Examples:
>>      NetBSD and FreeBSD support powerpc.
>>      FreeBSD's partitioner doesn't run on powerpc though.
>>      NetBSD I couldn't get to install.
>>      OpenBSD was easy.
>>
>>      Attempting to install Linux or NetBSD on an SGI machine apparently k=
>illed the machine.
>>      I couldn't get either to install or boot. One of them might not have=
> local console working.
>>      But again OpenBSD was easy and worked.
>>
>>
>>     My OpenBSD/sgimips CD was actually bad. But it worked enough to boot=
>=2C and the
>>     the install was then easy to fallback to over the network.
>>
>>
>> But they don't have kernel threads=2C so=2C while we work=2C we probably =
>scale the worst here.
>>   Besides=2C user threads are an /option/ on all Posix systems=2C only /r=
>equired/ on OpenBSD.
>>
>>
>> I think all the user interfaces are terrible though.
>> I am most productive by far on NT=2C using find-in-files countless times =
>daily in Visual C++ 5.0.
>>  It is so much better than command line grep=2C and it beats every other =
>IDE/editor I have tried=2C
>>  and I have tried many. Komodo Edit is so-so. MonoDevelop was promising=
>=2C but it refused
>>  to open *.m3 files as plain text. TextWrangler on Mac is so-so=2C what I=
> use for lack
>>  of anything good. Eclipse is confusing to install and I don't think work=
>ed well=2C but I forget.
>>
>>
>> Mac is distant second in productivity.
>>   At least I don't have to constantly flip the newlines and it has a fast=
> fork.
>>
>>
>> Everything else I can't even edit files on. I can't copy/paste=2C navigat=
>e quickly (e.g. esp. using
>> page up/down/home/end/mouse!). NT also has a fast console with half decen=
>t most support.
>>
>>
>> My most productive pattern is editing on NT and copying files around othe=
>rwise.
>>
>>
>> As well=2C consider that the NT Modula-3 backend is unique and pretty dar=
>n good.
>>   It is fast=2C in-proc=2C and always optimizes a certain amount.
>>   In its only mode=2C it generates significantly better code than unoptim=
>izing gcc.
>>
>>
>>  Compiling N files on NT takes one process to compile=2C codegen=2C write=
> objs files=2C
>> and then another one or two to link.
>>
>>
>> Compiling N files on the other systems takes one process to compile=2C N =
>runs
>> of m3cg to generate N asssembly files=2C N runs to run the assembler.
>>
>>
>> If you really need an *occasional* Posixy experience on NT=2C there is Cy=
>gwin and SFU/SUA.
>> Cygwin has a very slow fork and it is very noticable.
>> SFU/SUA has a "normally" fast fork=2C and it is very noticable.
>>
>>
>> FreeBSD=2C Solaris=2C NetBSD=2C Linux -- should all be about the same.
>>  (ok=2C Solaris/x86 support is only in head=2C not release).
>>
>>
>> Then there are the non-x86 ones=2C like HP-UX=2C OSF/1=2C Irix=2C AIX=2C =
>VMS... :)
>>
>>
>> Also=2C for Hudson purposes=2C we need Java.
>> That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
>> Linux now has good enough Java on all architectures.
>>   There was a project to eliminate all the assembly code. And we have no =
>problem
>>     e.g. now on Linux/sparc and Linux/powerpc.
>>
>> All the commercial systems probably suffice also.
>>
>>  - Jay
>>
>> ----------------------------------------
>>> From: dragisha at m3w.org
>>> To: mika at async.async.caltech.edu
>>> Date: Sun=2C 23 May 2010 00:32:25 +0200
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] OS for CM3
>>>
>>> There is no simple nor unique answer to this. I prefer Fedora=2C and I'v=
>e
>>> been using RedHat since 1996... Some people prefer RHEL=2C or CentOS if
>>> they like it freer. Jumped of SLS then Slackware I've been using from
>>> 1993-1995=2C and never looked back.
>>>
>>> Easy to administer and maintain=2C most of modern distros have GUI for
>>> every admin task.
>>>
>>> On Sat=2C 2010-05-22 at 14:53 -0700=2C Mika Nystrom wrote:
>>>> Hi Modula-3ers=2C
>>>>
>>>> Can anyone give me some advice on what OS to install on a new PC comput=
>e
>>>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
>>>> to be running is all written in Modula-3 with some C and Fortran thrown
>>>> in and I want to use CM3. The odd extra thing in Java and some analysis
>>>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
>>>>
>>>> I've always liked the ease of administration (i.e.=2C I'm an old dog an=
>d I
>>>> don't have to learn anything new) of FreeBSD=2C but the threading suppo=
>rt
>>>> seems much better with Linux? I do really want to run multi-threaded
>>>> programs across several CPUs.
>>>>
>>>> I am considering Debian/amd64. Any other recommendations=2C experiences=
>?
>>>>
>>>> Mika
>>>
>>> --
>>> Dragi=B9a Duri=E6
>>>
>>
> 		 	   		  =


From mika at async.async.caltech.edu  Sun May 23 02:13:49 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 22 May 2010 17:13:49 -0700
Subject: [M3devel] OS for CM3
In-Reply-To: <COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl> 
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
	<COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl>
Message-ID: <20100523001349.DCCE81A2096@async.async.caltech.edu>

Jay K writes:
>
>Modula-3 will run on almost anything. Install something we don't work on ye=
>t and give me ssh access. :)

Speaking of which, how's ALPHAOSF1 doing?  I'm trying to get a project
started that might involve Alphas...

   Mika


From jay.krell at cornell.edu  Sun May 23 03:06:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 23 May 2010 01:06:22 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <20100523001349.DCCE81A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>, ,
	<1274567545.29716.4.camel@localhost>,
	<COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl>,
	<20100523001349.DCCE81A2096@async.async.caltech.edu>
Message-ID: <COL101-W109BCFDBACAB678FB55CDAE6E60@phx.gbl>

I haven't set up any of my Alphas yet. Ssh access to yours? :)

 - Jay

> To: jay.krell at cornell.edu
> Date: Sat, 22 May 2010 17:13:49 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] OS for CM3
> 
> Jay K writes:
> >
> >Modula-3 will run on almost anything. Install something we don't work on ye=
> >t and give me ssh access. :)
> 
> Speaking of which, how's ALPHAOSF1 doing?  I'm trying to get a project
> started that might involve Alphas...
> 
>    Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100523/740d91b1/attachment-0001.html>

From jay.krell at cornell.edu  Sun May 23 03:49:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 23 May 2010 01:49:07 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <20100523000849.BA8E61A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
	<COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>,
	<20100523000849.BA8E61A2096@async.async.caltech.edu>
Message-ID: <COL101-W1561F238322CDB78B1CE53E6E60@phx.gbl>

FreeBSD is ok, NetBSD prob ok, not tested as much. OpenBSD not good.

 - Jay

> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] OS for CM3 
> Date: Sat, 22 May 2010 17:08:49 -0700
> From: mika at async.async.caltech.edu
> 
> Well I know all about the various OS tradeoffs, I was asking more
> about Modula-3 itself.
> 
> I want to use kernel threads, so I can share large data structures 
> across CPUs.  This is for production work, not a development platform.
> My main development platform will probably stay FreeBSD/i386 for a while.
> 
> Yes I agree Linux is chaotic.  But I can't stand Windows, because I
> hate GUIs (because I can't automate them and my philosophy is to make
> the computer work for me, not the other way around).  I know all the
> old-fashioned Unix admin commands by heart (I am somewhat dismayed
> that the old kill -1 convention for making daemons re-read their config
> files seems to have fallen by the wayside!)  My .twmrc is dated 1992.
> And PageUp etc work fine in emacs for me :-)
> 
> In other words the system will just have command-line access.  In
> fact it's supposed to sit in a locked machine room.
> 
> Err, to the point... maybe it got lost in the vague generality of the
> question.  
> 
> My real question is: do kernel threads work on *BSD at all?
> 
> I haven't done a proper back to back test but the Debian system
> "seems faster" than FreeBSD, running on the same amd64 hardware.
> 
> Or perhaps.. crazy question.. can one make a hackintosh/amd64 out of a
> 16-core machine?
> 
> I seem to remember Tony made some (bad) comments about FreeBSD kernel
> threads a few months ago...
> 
>     Mika
> 
> Jay K writes:
> >
> >ps: Slackware was fine back when I used it. RedHat is ok=2C but it at least=
> > used to take forever to do any package management compared to Ubuntu/Debia=
> >n.
> >Suse has/had RedHat's problem=2C also being rpm basedi but also seemed to l=
> >ead in gui/managability.
> >
> >
> >Anyway=2C other than Mac and NT=2C all my other systems are now ssh command=
> > line and impossible to do much with. :)
> >
> >
> >ps: I also like *BSD due to the reduced number of choices=2C and the "integ=
> >rated build"=2C where you can build a bit
> >more in one nice go=2C not just the kernel. Linux is so darn chaotic.
> >But I rarely take any advantage of this.
> >I would really like=2C whatever I run=2C to build the entire thing from sou=
> >rce=2C and do it fairly easily.
> >=A0Have the whole thing be debuggable.
> >=A0Cross building support would be nice too=2C though lately people seem to=
> > give up and use qemu.
> >=A0 Too much building stuff wants to run as it builds=2C like using autocon=
> >f.
> >
> >
> >=A0- Jay
> >
> >----------------------------------------
> >> From: jay.krell at cornell.edu
> >> To: dragisha at m3w.org=3B mika at async.async.caltech.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: RE: [M3devel] OS for CM3
> >> Date: Sat=2C 22 May 2010 23:35:52 +0000
> >>
> >>
> >> Modula-3 will run on almost anything. Install something we don't work on =
> >yet and give me ssh access. :)
> >> Like get a Loongson laptop -- comes with Linux/MIPS but can also run Open=
> >BSD and maybe others.
> >> Or=2C install something we don't have yet in Hudson yet=2C e.g. NetBSD/am=
> >d64=2C and have Olaf add jobs for it.
> >>
> >> Seriously=2C for Hudson purposes=2C NetBSD/amd64 is probably the best=2C =
> >followed by NetBSD/x86.
> >> I'll set these up eventually.
> >>
> >>
> >> Regarding Linux=2C I've been using Debian=2C because it has about the bes=
> >t support for multiple architectures.
> >>   And then the same "experience" across all of them -- same installer and=
> > package management.
> >>
> >>
> >> Gentoo would be the next or previous choice -- not clear what the ppc64 s=
> >upport is in Debian.
> >> It helps that I first used wimpy Ubuntu before moving up to the supposedl=
> >y manly Debian.
> >> Gentoo I've had trouble getting to install+boot.
> >>
> >>
> >> OpenBSD has about the best install experience imho and a certain hard to =
> >capture purity about it.
> >>   Examples:
> >>      NetBSD and FreeBSD support powerpc.
> >>      FreeBSD's partitioner doesn't run on powerpc though.
> >>      NetBSD I couldn't get to install.
> >>      OpenBSD was easy.
> >>
> >>      Attempting to install Linux or NetBSD on an SGI machine apparently k=
> >illed the machine.
> >>      I couldn't get either to install or boot. One of them might not have=
> > local console working.
> >>      But again OpenBSD was easy and worked.
> >>
> >>
> >>     My OpenBSD/sgimips CD was actually bad. But it worked enough to boot=
> >=2C and the
> >>     the install was then easy to fallback to over the network.
> >>
> >>
> >> But they don't have kernel threads=2C so=2C while we work=2C we probably =
> >scale the worst here.
> >>   Besides=2C user threads are an /option/ on all Posix systems=2C only /r=
> >equired/ on OpenBSD.
> >>
> >>
> >> I think all the user interfaces are terrible though.
> >> I am most productive by far on NT=2C using find-in-files countless times =
> >daily in Visual C++ 5.0.
> >>  It is so much better than command line grep=2C and it beats every other =
> >IDE/editor I have tried=2C
> >>  and I have tried many. Komodo Edit is so-so. MonoDevelop was promising=
> >=2C but it refused
> >>  to open *.m3 files as plain text. TextWrangler on Mac is so-so=2C what I=
> > use for lack
> >>  of anything good. Eclipse is confusing to install and I don't think work=
> >ed well=2C but I forget.
> >>
> >>
> >> Mac is distant second in productivity.
> >>   At least I don't have to constantly flip the newlines and it has a fast=
> > fork.
> >>
> >>
> >> Everything else I can't even edit files on. I can't copy/paste=2C navigat=
> >e quickly (e.g. esp. using
> >> page up/down/home/end/mouse!). NT also has a fast console with half decen=
> >t most support.
> >>
> >>
> >> My most productive pattern is editing on NT and copying files around othe=
> >rwise.
> >>
> >>
> >> As well=2C consider that the NT Modula-3 backend is unique and pretty dar=
> >n good.
> >>   It is fast=2C in-proc=2C and always optimizes a certain amount.
> >>   In its only mode=2C it generates significantly better code than unoptim=
> >izing gcc.
> >>
> >>
> >>  Compiling N files on NT takes one process to compile=2C codegen=2C write=
> > objs files=2C
> >> and then another one or two to link.
> >>
> >>
> >> Compiling N files on the other systems takes one process to compile=2C N =
> >runs
> >> of m3cg to generate N asssembly files=2C N runs to run the assembler.
> >>
> >>
> >> If you really need an *occasional* Posixy experience on NT=2C there is Cy=
> >gwin and SFU/SUA.
> >> Cygwin has a very slow fork and it is very noticable.
> >> SFU/SUA has a "normally" fast fork=2C and it is very noticable.
> >>
> >>
> >> FreeBSD=2C Solaris=2C NetBSD=2C Linux -- should all be about the same.
> >>  (ok=2C Solaris/x86 support is only in head=2C not release).
> >>
> >>
> >> Then there are the non-x86 ones=2C like HP-UX=2C OSF/1=2C Irix=2C AIX=2C =
> >VMS... :)
> >>
> >>
> >> Also=2C for Hudson purposes=2C we need Java.
> >> That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
> >> Linux now has good enough Java on all architectures.
> >>   There was a project to eliminate all the assembly code. And we have no =
> >problem
> >>     e.g. now on Linux/sparc and Linux/powerpc.
> >>
> >> All the commercial systems probably suffice also.
> >>
> >>  - Jay
> >>
> >> ----------------------------------------
> >>> From: dragisha at m3w.org
> >>> To: mika at async.async.caltech.edu
> >>> Date: Sun=2C 23 May 2010 00:32:25 +0200
> >>> CC: m3devel at elegosoft.com
> >>> Subject: Re: [M3devel] OS for CM3
> >>>
> >>> There is no simple nor unique answer to this. I prefer Fedora=2C and I'v=
> >e
> >>> been using RedHat since 1996... Some people prefer RHEL=2C or CentOS if
> >>> they like it freer. Jumped of SLS then Slackware I've been using from
> >>> 1993-1995=2C and never looked back.
> >>>
> >>> Easy to administer and maintain=2C most of modern distros have GUI for
> >>> every admin task.
> >>>
> >>> On Sat=2C 2010-05-22 at 14:53 -0700=2C Mika Nystrom wrote:
> >>>> Hi Modula-3ers=2C
> >>>>
> >>>> Can anyone give me some advice on what OS to install on a new PC comput=
> >e
> >>>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
> >>>> to be running is all written in Modula-3 with some C and Fortran thrown
> >>>> in and I want to use CM3. The odd extra thing in Java and some analysis
> >>>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
> >>>>
> >>>> I've always liked the ease of administration (i.e.=2C I'm an old dog an=
> >d I
> >>>> don't have to learn anything new) of FreeBSD=2C but the threading suppo=
> >rt
> >>>> seems much better with Linux? I do really want to run multi-threaded
> >>>> programs across several CPUs.
> >>>>
> >>>> I am considering Debian/amd64. Any other recommendations=2C experiences=
> >?
> >>>>
> >>>> Mika
> >>>
> >>> --
> >>> Dragi=B9a Duri=E6
> >>>
> >>
> > 		 	   		  =
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100523/c9ebf99a/attachment-0001.html>

From dragisha at m3w.org  Sun May 23 04:14:25 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 23 May 2010 04:14:25 +0200
Subject: [M3devel] ***SPAM*** RE:  OS for CM3
In-Reply-To: <COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
	,<1274567545.29716.4.camel@localhost>
	<COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>
Message-ID: <1274580865.29716.6.camel@localhost>

And of course .deb is superior to .rpm.. Ok, you win! :)

RedHat package management compared do Fedora's yum is Stone Age. Also -
yum supports multiarch nicely, as does rpm it's based on.

On Sat, 2010-05-22 at 23:40 +0000, Jay K wrote:
> 
> ps: Slackware was fine back when I used it. RedHat is ok, but it at
> least used to take forever to do any package management compared to
> Ubuntu/Debian.
> Suse has/had RedHat's problem, also being rpm basedi but also seemed
> to lead in gui/managability.
> 
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From dabenavidesd at yahoo.es  Tue May 25 06:07:24 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 25 May 2010 04:07:24 +0000 (GMT)
Subject: [M3devel] OS for CM3
In-Reply-To: <20100522215317.E428D1A2096@async.async.caltech.edu>
Message-ID: <729398.10895.qm@web23605.mail.ird.yahoo.com>

Hi:
if easy of administration is what you are looking for maybe a bsd flavour a is the right choice of use probably it would be a linux distro but a common sense of easy administration and use like ubuntu rh/centos server or why not a gentoo or archlinux if customization is what you want to add more cores linux will support up to 1024 and the small or medium size servers are commonly used in this servers sizes I guess you have a good choice to take advantage, how many does support Win server 2k3 (up to 64?) an another bsd up to how many?  

Hope it helps, thanks in advance

--- El s?b, 22/5/10, Mika Nystrom <mika at async.async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.async.caltech.edu>
> Asunto: [M3devel] OS for CM3
> Para: m3devel at elegosoft.com
> Fecha: s?bado, 22 de mayo, 2010 16:53
> Hi Modula-3ers,
> 
> Can anyone give me some advice on what OS to install on a
> new PC compute
> server with 16 to 24 cores and 16 to 32 GB of RAM? 
> The code I'm going
> to be running is all written in Modula-3 with some C and
> Fortran thrown
> in and I want to use CM3.  The odd extra thing in Java
> and some analysis
> in R.  Currently I'm stuck with PM3 on FreeBSD/i386.
> 
> I've always liked the ease of administration (i.e., I'm an
> old dog and I
> don't have to learn anything new) of FreeBSD, but the
> threading support
> seems much better with Linux?  I do really want to run
> multi-threaded
> programs across several CPUs.
> 
> I am considering Debian/amd64.  Any other
> recommendations, experiences?
> 
>     Mika
> 


      


From jay.krell at cornell.edu  Wed May 26 07:58:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 05:58:54 +0000
Subject: [M3devel] separate directory for gcc-4.5? import binutils?
Message-ID: <COL101-W500D7CADC89644958BFA09E6E90@phx.gbl>


Anyone object if I create gcc-4.5.0 or gcc-4.5 next to m3cc/gcc?
Anyone object if I import binutils?

Both are tenuous but possibly useful.


Importing gcc-4.5.0 allows for an easier/slower move to it, with somewhat easier to read history.

?- m3cc/src/m3makefile could chose between gcc and gcc-4.5.0. 
?? As they are tested they could move to gcc-4.5.0.

?- The original import wouldn't have the Modula-3 diffs.
?? It might be possible to have CVS do the future merges.
?? At least maybe to 4.5.1, 4.5.2, etc.
?? Which is a reason to call it 4.5.

?- But it does add considerably to the source tree size and time to cvs checkout/upd.

?- We'd probably want to symlink gmp/mpfr, and now mpc.
?? Really those should probably be *not* under gcc, but outside,
?? build them first, point gcc at them the "same" way it would.
?? Point being
???? - more granular "clean"
???? - split up the tree in terms of history/import/sharing 


Importing binutils might kinda/sorta allow better cross support.
gcc+binutils are 2 out of 3 pieces need to build every complete cross tools.
The third piece is headers/libraries for each system.


One can at least assemble the assembly to object files.


Or not. I can also merge our changes into 4.5.0, test a few but not all targets, and go.
e.g. Darwin/amd64, Linux/x86, Solaris/sparc32.
?

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Wed May 26 08:05:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 06:05:25 +0000
Subject: [M3devel] m3cc static chain stuff
Message-ID: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>


Can any of this be removed?
Can we really not just use "unfold-nested-procs" like NT386?
We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
generally a considered the responsibility of optimizers.

Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
Maybe I'll try without.


diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
--- /src/orig/gcc-4.3.0/gcc/tree-nested.c??? 2008-02-15 09:36:43.000000000 -0800
+++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c??? 2010-05-09 22:27:58.000000000 -0700


-/* Build or return the RECORD_TYPE that describes the frame state that is
-?? shared between INFO->CONTEXT and its nested functions.? This record will
-?? not be complete until finalize_nesting_tree; up until that point we'll
+/* This must agree with the string defined by the same name in m3gdb, file
+?? m3-util.c */ 
+static const char * nonlocal_var_rec_name = "_nonlocal_var_rec"; 
+
+/* Build or return the RECORD_TYPE that describes the non-local frame struct 
+?? that is shared between INFO->CONTEXT and its nested functions.? This record 
+?? will not be complete until finalize_nesting_tree; up until that point we'll
??? be adding fields as necessary.
?
??? We also build the DECL that represents this frame in the function.? */
@@ -209,7 +224,8 @@
?????? free (name);
?
?????? info->frame_type = type;
-????? info->frame_decl = create_tmp_var_for (info, type, "FRAME");
+????? info->frame_decl 
+??????? = create_tmp_var_for (info, type, nonlocal_var_rec_name);
?
?????? /* ??? Always make it addressable for now, since it is meant to
???? ?be pointed to by the static chain pointer.? This pessimizes
@@ -218,6 +234,8 @@
???? ?reachable, but the true pessimization is to create the non-
???? ?local frame structure in the first place.? */
?????? TREE_ADDRESSABLE (info->frame_decl) = 1;
+????? /* m3gdb needs to know about this variable. */ 
+????? DECL_IGNORED_P (info->frame_decl) = 0;? 
???? }
?? return type;
?}
@@ -290,6 +308,10 @@
?? return *slot;
?}
?
+/* This must agree with the string defined by the same name in m3gdb, file
+?? m3_util.c */ 
+static const char * static_link_var_name = "_static_link_var"; 
+
?/* Build or return the variable that holds the static chain within
??? INFO->CONTEXT.? This variable may only be used within INFO->CONTEXT.? */
?
@@ -310,9 +332,14 @@
???? ?Note also that it's represented as a parameter.? This is more
???? ?close to the truth, since the initial value does come from 
???? ?the caller.? */
-????? decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
+????? decl = build_decl 
+?????????????? (PARM_DECL, get_identifier (static_link_var_name), type);
+????? TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */ 
?????? DECL_ARTIFICIAL (decl) = 1;
-????? DECL_IGNORED_P (decl) = 1;
+
+????? /* m3gdb needs to know about this variable. */ 
+????? DECL_IGNORED_P (decl) = 0;
+
?????? TREE_USED (decl) = 1;
?????? DECL_CONTEXT (decl) = info->context;
?????? DECL_ARG_TYPE (decl) = type;
@@ -326,7 +353,11 @@
?? return decl;
?}
?
-/* Build or return the field within the non-local frame state that holds
+/* This must agree with the string defined by the same name in m3gdb, file
+?? m3_util.c */ 
+static const char * static_link_copy_field_name = "_static_link_copy_field"; 
+
+/* Build or return the field within the non-local frame struct that holds
??? the static chain for INFO->CONTEXT.? This is the way to walk back up
??? multiple nesting levels.? */
?
@@ -339,10 +370,12 @@
?????? tree type = build_pointer_type (get_frame_type (info->outer));
?
?????? field = make_node (FIELD_DECL);
-????? DECL_NAME (field) = get_identifier ("__chain");
+????? DECL_NAME (field) = get_identifier (static_link_copy_field_name);
?????? TREE_TYPE (field) = type;
?????? DECL_ALIGN (field) = TYPE_ALIGN (type);
?????? DECL_NONADDRESSABLE_P (field) = 1;
+????? /* m3gdb should know about this field. */ 
+????? DECL_IGNORED_P (field) = 0;? 
?
?????? insert_field_into_struct (get_frame_type (info), field);
?
@@ -465,7 +498,7 @@
?? return *slot;
?} 
?
-/* Build or return the field within the non-local frame state that holds
+/* Build or return the field within the non-local frame struct that holds
??? the non-local goto "jmp_buf".? The buffer itself is maintained by the
??? rtl middle-end as dynamic stack space is allocated.? */
?
@@ -1620,6 +1653,9 @@
?? switch (TREE_CODE (t))
???? {
???? case ADDR_EXPR:
+????? if (TREE_STATIC (t))
+??? break;
+
?????? /* Build
???? ?? T.1 = &CHAIN->tramp;
???? ?? T.2 = __builtin_adjust_trampoline (T.1);
@@ -1714,6 +1750,22 @@
???? }
?????? break;
?
+??? case STATIC_CHAIN_EXPR:
+????? decl = TREE_OPERAND (t, 0);
+????? target_context = decl_function_context (decl);
+????? if (target_context)
+??? {
+??? ? if (info->context == target_context)
+??? ??? {
+??? ????? /* Make sure frame_decl gets created.? */
+??? ????? (void) get_frame_type (info);
+??? ??? }
+??? ? *tp = get_static_chain (info, target_context, &wi->tsi);
+??? }
+????? else
+??? *tp = null_pointer_node;
+????? break;
+
???? case RETURN_EXPR:
???? case GIMPLE_MODIFY_STMT:
???? case WITH_SIZE_EXPR:
@@ -1768,13 +1820,22 @@
?? return NULL_TREE;
?}
?
+static bool
+debug_static_links (void) 
+{ return
+??? write_symbols != NO_DEBUG
+??? && debug_info_level != DINFO_LEVEL_NONE
+??? && debug_info_level != DINFO_LEVEL_TERSE;
+
+} /* debug_static_links */ 
+
?/* Walk the nesting tree starting with ROOT, depth first.? Convert all
??? trampolines and call expressions.? On the way back up, determine if
??? a nested function actually uses its static chain; if not, remember that.? */
?
?static void
?convert_all_function_calls (struct nesting_info *root)
-{
+{ 
?? do
???? {
?????? if (root->inner)
@@ -1784,7 +1845,10 @@
?????? walk_function (convert_call_expr, root);
?
?????? /* If the function does not use a static chain, then remember that.? */
-????? if (root->outer && !root->chain_decl && !root->chain_field)
+????? if (root->outer && !root->chain_decl && !root->chain_field
+/* REMOVE ME: */ 
+????????? /* && !debug_static_links () */ 
+???????? )
???? DECL_NO_STATIC_CHAIN (root->context) = 1;
?????? else
???? gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
@@ -1806,6 +1870,21 @@
?? tree context = root->context;
?? struct function *sf;
?
+/* REMOVEME: */ 
+? /* If this is a nested function and we are supporting debugging via
+???? m3gdb, we always need a chain_decl, so m3gdb can find the static 
+???? chain, even if the programmer's code doesn't use it. */ 
+? if (false && root->outer && debug_static_links () )
+??? { tree static_chain_decl, temp, stmt;
+????? /* This is a desperate attempt to get later code generation to 
+???????? store the static link.? If it works, it'll be a miracle. */ 
+????? static_chain_decl = get_chain_decl (root); 
+????? stmt = build_addr (static_chain_decl, root->context); 
+????? temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
+????? stmt = build_gimple_modify_stmt (temp, static_chain_decl);
+????? append_to_statement_list (stmt, &stmt_list);
+??? } 
+
?? /* If we created a non-local frame type or decl, we need to lay them
????? out at this time.? */
?? if (root->frame_type)
@@ -1912,7 +1991,7 @@
????? proper BIND_EXPR.? */
?? if (root->new_local_var_chain)
???? declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
-??? ??? ? false);
+??? ??? ? true);
?? if (root->debug_var_chain)
???? declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
???? ??? ? true);


 		 	   		  

From jay.krell at cornell.edu  Wed May 26 09:50:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 07:50:40 +0000
Subject: [M3devel] newer versions might obviate some of our changes
Message-ID: <COL101-W329B816AD3C1C3C5DBD3DE6E90@phx.gbl>


I haven't tracked down everything, but in a few cases, I notice that functions we modified
are removed. It appears we might have been fixing bugs that got fixed by gcc later.

Here is an example:

We changed mark_non_addressable in tree-ssa-alias.c.

First it changed to something else:

2008-06-04? Richard Guenther? <rguenther at suse.de>

??? * tree-flow-inline.h (is_global_var): Do not check TREE_STATIC on MTAGs.
??? (is_call_clobbered): Always check var_ann->call_clobbered.
??? (mark_call_clobbered): Always set var_ann->call_clobbered.
??? (clear_call_clobbered): Always clear var_ann->call_clobbered.
??? * tree-ssa-alias.c (mark_non_addressable): Use clear_call_clobbered.


then that something else got removed:


2009-04-03? Richard Guenther? <rguenther at suse.de>

??? PR middle-end/13146
??? PR tree-optimization/23940
... many ..
??? * tree-flow-inline.h (gimple_aliases_computed_p,
??? gimple_addressable_vars, gimple_call_clobbered_vars,
??? gimple_call_used_vars, gimple_global_var, may_aliases, memory_partition,
??? factoring_name_p, mark_call_clobbered, clear_call_clobbered,
??? compare_ssa_operands_equal, symbol_mem_tag, set_symbol_mem_tag,
??? gimple_mem_ref_stats): Remove.


In tree-cfg.c, we modified remove_useless_stmts_bind:

????? /* Removing the BIND_EXPR will break Modula-3 debug information by? 
???????? making explicitly programmed blocks disappear. */ 
????? && ( write_symbols == NO_DEBUG
?????????? || debug_info_level == DINFO_LEVEL_NONE
?????????? || debug_info_level == DINFO_LEVEL_TERSE ))


the change seems dubious to me -- generating symbols should NOT change codegen.

Anyway, this function and a lot around it is gone now:


2009-10-08? Michael Matz? <matz at suse.de>

??? PR middle-end/41573
...
??? * tree-cfg.c (struct rus_data, remove_useless_stmts_warn_notreached,
??? remove_useless_stmts_cond, remove_useless_stmts_tf,
??? remove_useless_stmts_tc, remove_useless_stmts_bind,
??? remove_useless_stmts_goto, remove_useless_stmts_label,
??? remove_useless_stmts_1, remove_useless_stmts,
??? pass_remove_useless_stmts): Remove.


also, some of the OpenBSD patches got applied, at least x86 and sparc64.
Not clear about powerpc and amd64. (maybe amd64 is x86 -m64? powerpc
definitely seems to be missing).


I should look more closely, see if they were fixing something similar to what we were
and make sure they didn't just move the problem elsewhere.


Later,
?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 09:55:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 07:55:19 +0000
Subject: [M3devel] m3cc static chain stuff
Message-ID: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>


I'm going to try to keep the code that seems to do anything, however:

1) if (false && 

?I plan to remove that.


2)
+????? if (root->outer && !root->chain_decl && !root->chain_field
+/* REMOVE ME: */ 
+????????? /* && !debug_static_links () */ 
+???????? )


I can't find where that would apply, and it is commented out anyway so I'll remove it.


I'm open to arguments though. :)

dbxout.c
+#if 0
+/* Code copied from 1.4.2.2: */ 


I can cheaply enough keep that...should we really though?


I really think we can reduce our changes.
Enough type information should be passed around so that regular gdb works. Imho.
?And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
? don't cause internal compiler errors. So that debug info might be generated on systems
? that don't support stabs though granted they are few and minor (hppa64-hpux).
Nested functions should be transformed to not be nested. Imho.
Optimization should be allowed to inhibit debugging as much as it does for any other language.


I realize the type information getting around is probably a lot of work.
And it is needed in m3back also, and probably not shared work.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: m3cc static chain stuff
> Date: Wed, 26 May 2010 06:05:25 +0000
>
>
> Can any of this be removed?
> Can we really not just use "unfold-nested-procs" like NT386?
> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
> generally a considered the responsibility of optimizers.
>
> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
> Maybe I'll try without.
>
>
> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
>
>
> -/* Build or return the RECORD_TYPE that describes the frame state that is
> -   shared between INFO->CONTEXT and its nested functions.  This record will
> -   not be complete until finalize_nesting_tree; up until that point we'll
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3-util.c */
> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
> +
> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
> +   that is shared between INFO->CONTEXT and its nested functions.  This record
> +   will not be complete until finalize_nesting_tree; up until that point we'll
>     be adding fields as necessary.
>
>     We also build the DECL that represents this frame in the function.  */
> @@ -209,7 +224,8 @@
>        free (name);
>
>        info->frame_type = type;
> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
> +      info->frame_decl
> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>
>        /* ??? Always make it addressable for now, since it is meant to
>       be pointed to by the static chain pointer.  This pessimizes
> @@ -218,6 +234,8 @@
>       reachable, but the true pessimization is to create the non-
>       local frame structure in the first place.  */
>        TREE_ADDRESSABLE (info->frame_decl) = 1;
> +      /* m3gdb needs to know about this variable. */
> +      DECL_IGNORED_P (info->frame_decl) = 0;
>      }
>    return type;
>  }
> @@ -290,6 +308,10 @@
>    return *slot;
>  }
>
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */
> +static const char * static_link_var_name = "_static_link_var";
> +
>  /* Build or return the variable that holds the static chain within
>     INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>
> @@ -310,9 +332,14 @@
>       Note also that it's represented as a parameter.  This is more
>       close to the truth, since the initial value does come from
>       the caller.  */
> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
> +      decl = build_decl
> +               (PARM_DECL, get_identifier (static_link_var_name), type);
> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>        DECL_ARTIFICIAL (decl) = 1;
> -      DECL_IGNORED_P (decl) = 1;
> +
> +      /* m3gdb needs to know about this variable. */
> +      DECL_IGNORED_P (decl) = 0;
> +
>        TREE_USED (decl) = 1;
>        DECL_CONTEXT (decl) = info->context;
>        DECL_ARG_TYPE (decl) = type;
> @@ -326,7 +353,11 @@
>    return decl;
>  }
>
> -/* Build or return the field within the non-local frame state that holds
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */
> +static const char * static_link_copy_field_name = "_static_link_copy_field";
> +
> +/* Build or return the field within the non-local frame struct that holds
>     the static chain for INFO->CONTEXT.  This is the way to walk back up
>     multiple nesting levels.  */
>
> @@ -339,10 +370,12 @@
>        tree type = build_pointer_type (get_frame_type (info->outer));
>
>        field = make_node (FIELD_DECL);
> -      DECL_NAME (field) = get_identifier ("__chain");
> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>        TREE_TYPE (field) = type;
>        DECL_ALIGN (field) = TYPE_ALIGN (type);
>        DECL_NONADDRESSABLE_P (field) = 1;
> +      /* m3gdb should know about this field. */
> +      DECL_IGNORED_P (field) = 0;
>
>        insert_field_into_struct (get_frame_type (info), field);
>
> @@ -465,7 +498,7 @@
>    return *slot;
>  }
>
> -/* Build or return the field within the non-local frame state that holds
> +/* Build or return the field within the non-local frame struct that holds
>     the non-local goto "jmp_buf".  The buffer itself is maintained by the
>     rtl middle-end as dynamic stack space is allocated.  */
>
> @@ -1620,6 +1653,9 @@
>    switch (TREE_CODE (t))
>      {
>      case ADDR_EXPR:
> +      if (TREE_STATIC (t))
> +    break;
> +
>        /* Build
>         T.1 = &CHAIN->tramp;
>         T.2 = __builtin_adjust_trampoline (T.1);
> @@ -1714,6 +1750,22 @@
>      }
>        break;
>
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
>      case RETURN_EXPR:
>      case GIMPLE_MODIFY_STMT:
>      case WITH_SIZE_EXPR:
> @@ -1768,13 +1820,22 @@
>    return NULL_TREE;
>  }
>
> +static bool
> +debug_static_links (void)
> +{ return
> +    write_symbols != NO_DEBUG
> +    && debug_info_level != DINFO_LEVEL_NONE
> +    && debug_info_level != DINFO_LEVEL_TERSE;
> +
> +} /* debug_static_links */
> +
>  /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>     trampolines and call expressions.  On the way back up, determine if
>     a nested function actually uses its static chain; if not, remember that.  */
>
>  static void
>  convert_all_function_calls (struct nesting_info *root)
> -{
> +{
>    do
>      {
>        if (root->inner)
> @@ -1784,7 +1845,10 @@
>        walk_function (convert_call_expr, root);
>
>        /* If the function does not use a static chain, then remember that.  */
> -      if (root->outer && !root->chain_decl && !root->chain_field)
> +      if (root->outer && !root->chain_decl && !root->chain_field
> +/* REMOVE ME: */
> +          /* && !debug_static_links () */
> +         )
>      DECL_NO_STATIC_CHAIN (root->context) = 1;
>        else
>      gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
> @@ -1806,6 +1870,21 @@
>    tree context = root->context;
>    struct function *sf;
>
> +/* REMOVEME: */
> +  /* If this is a nested function and we are supporting debugging via
> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
> +     chain, even if the programmer's code doesn't use it. */
> +  if (false && root->outer && debug_static_links () )
> +    { tree static_chain_decl, temp, stmt;
> +      /* This is a desperate attempt to get later code generation to
> +         store the static link.  If it works, it'll be a miracle. */
> +      static_chain_decl = get_chain_decl (root);
> +      stmt = build_addr (static_chain_decl, root->context);
> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
> +      append_to_statement_list (stmt, &stmt_list);
> +    }
> +
>    /* If we created a non-local frame type or decl, we need to lay them
>       out at this time.  */
>    if (root->frame_type)
> @@ -1912,7 +1991,7 @@
>       proper BIND_EXPR.  */
>    if (root->new_local_var_chain)
>      declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
> -          false);
> +          true);
>    if (root->debug_var_chain)
>      declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>            true);
>
>
>
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 13:58:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 11:58:09 +0000
Subject: [M3devel] dbxout_static_chain_decl?
Message-ID: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>


Rodney, you added this function, along with a comment that says it doesn't actually work.
Does it work?
Does it accomplish anything?
Can I remove it and its calls?

/* Special-purpose function to write stabs for the static_chain_decl. 
?? So far, this is not working.? m3gdb needs the place in the activation
?? record where the SL is stored.? Right now, the SL is not necessarily
?? stored at all, but may just be kept in a register.? DECL_RTL and 
?? DECL_INCOMING_RTL may both have register expressions.? But stabs
?? entries for register variables, of kind N_RSYM, are currently ignored
?? by gdb in dbxread.c, and making it read them could create problems
?? elsewhere, because there can be other variables for which both an
?? N_RSYM and an N_LSYM stabs entry are created.?? 
*/ 
static int 
dbxout_static_chain_decl (tree decl) 

It was added 19 months ago by:
? http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9

as well, do we need the #if 0 code added then?

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 16:20:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 14:20:04 +0000
Subject: [M3devel] DECL_LANG_SPECIFIC and casts?
Message-ID: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>


Tony, this thing where we do:

? DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
...

????? tree var = (tree)DECL_LANG_SPECIFIC(index);


Is this running afoul of the gcc garbage collector?
? Seems likely.

And does it matter?
? Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
?assuming m3_write_globals is called near the end.


Thing is:
struct lang_identifier GTY(()) ...
union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
struct lang_type GTY(()) ...
typedef struct lang_decl GTY(()) ...
struct language_function GTY(()) ...


Which are nearly unused, cause me grief.
They have to be different for 4.5 vs. 4.2/4.3.
? Just the GTY needs to be moved to before the union/struct tag.


I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
? I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
?? aren't so small like ours so I'd rather not.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Wed May 26 16:26:32 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 26 May 2010 10:26:32 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>
References: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>
Message-ID: <88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>

On 26 May 2010, at 03:55, Jay K wrote:

> 
> I'm going to try to keep the code that seems to do anything, however:
> 
> 1) if (false && 
> 
>  I plan to remove that.
> 
> 
> 2)
> +      if (root->outer && !root->chain_decl && !root->chain_field
> +/* REMOVE ME: */ 
> +          /* && !debug_static_links () */ 
> +         )
> 
> 
> I can't find where that would apply, and it is commented out anyway so I'll remove it.
> 
> 
> I'm open to arguments though. :)
> 
> dbxout.c
> +#if 0
> +/* Code copied from 1.4.2.2: */ 
> 
> 
> I can cheaply enough keep that...should we really though?
> 
> 
> I really think we can reduce our changes.
> Enough type information should be passed around so that regular gdb works. Imho.

Possibly, but M3 has a very different notion of type to C.  Moreover, it is extremely valuable to have the M3 type ids there so that functionality can map back to the types in the M3 runtime system.  It would be possible to implement much of the m3gdb debugging support by calling back into the language run-time passing the language type ids instead of relying on hand-crafted C in m3gdb.  But I agree that more type information would be good, particularly for records.

>  And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
>   don't cause internal compiler errors. So that debug info might be generated on systems
>   that don't support stabs though granted they are few and minor (hppa64-hpux).
> Nested functions should be transformed to not be nested. Imho.

I don't understand this.  Nested functions must be nested in the sense that they have static chain information provided by gcc.

> Optimization should be allowed to inhibit debugging as much as it does for any other language.

What do you mean by this?

> 
> 
> I realize the type information getting around is probably a lot of work.
> And it is needed in m3back also, and probably not shared work.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Subject: m3cc static chain stuff
>> Date: Wed, 26 May 2010 06:05:25 +0000
>> 
>> 
>> Can any of this be removed?
>> Can we really not just use "unfold-nested-procs" like NT386?
>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>> generally a considered the responsibility of optimizers.
>> 
>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>> Maybe I'll try without.
>> 
>> 
>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
>> 
>> 
>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>> -   shared between INFO->CONTEXT and its nested functions.  This record will
>> -   not be complete until finalize_nesting_tree; up until that point we'll
>> +/* This must agree with the string defined by the same name in m3gdb, file
>> +   m3-util.c */
>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>> +
>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>> +   that is shared between INFO->CONTEXT and its nested functions.  This record
>> +   will not be complete until finalize_nesting_tree; up until that point we'll
>>    be adding fields as necessary.
>> 
>>    We also build the DECL that represents this frame in the function.  */
>> @@ -209,7 +224,8 @@
>>       free (name);
>> 
>>       info->frame_type = type;
>> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>> +      info->frame_decl
>> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>> 
>>       /* ??? Always make it addressable for now, since it is meant to
>>      be pointed to by the static chain pointer.  This pessimizes
>> @@ -218,6 +234,8 @@
>>      reachable, but the true pessimization is to create the non-
>>      local frame structure in the first place.  */
>>       TREE_ADDRESSABLE (info->frame_decl) = 1;
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (info->frame_decl) = 0;
>>     }
>>   return type;
>> }
>> @@ -290,6 +308,10 @@
>>   return *slot;
>> }
>> 
>> +/* This must agree with the string defined by the same name in m3gdb, file
>> +   m3_util.c */
>> +static const char * static_link_var_name = "_static_link_var";
>> +
>> /* Build or return the variable that holds the static chain within
>>    INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>> 
>> @@ -310,9 +332,14 @@
>>      Note also that it's represented as a parameter.  This is more
>>      close to the truth, since the initial value does come from
>>      the caller.  */
>> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>> +      decl = build_decl
>> +               (PARM_DECL, get_identifier (static_link_var_name), type);
>> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>       DECL_ARTIFICIAL (decl) = 1;
>> -      DECL_IGNORED_P (decl) = 1;
>> +
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (decl) = 0;
>> +
>>       TREE_USED (decl) = 1;
>>       DECL_CONTEXT (decl) = info->context;
>>       DECL_ARG_TYPE (decl) = type;
>> @@ -326,7 +353,11 @@
>>   return decl;
>> }
>> 
>> -/* Build or return the field within the non-local frame state that holds
>> +/* This must agree with the string defined by the same name in m3gdb, file
>> +   m3_util.c */
>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>> +
>> +/* Build or return the field within the non-local frame struct that holds
>>    the static chain for INFO->CONTEXT.  This is the way to walk back up
>>    multiple nesting levels.  */
>> 
>> @@ -339,10 +370,12 @@
>>       tree type = build_pointer_type (get_frame_type (info->outer));
>> 
>>       field = make_node (FIELD_DECL);
>> -      DECL_NAME (field) = get_identifier ("__chain");
>> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>       TREE_TYPE (field) = type;
>>       DECL_ALIGN (field) = TYPE_ALIGN (type);
>>       DECL_NONADDRESSABLE_P (field) = 1;
>> +      /* m3gdb should know about this field. */
>> +      DECL_IGNORED_P (field) = 0;
>> 
>>       insert_field_into_struct (get_frame_type (info), field);
>> 
>> @@ -465,7 +498,7 @@
>>   return *slot;
>> }
>> 
>> -/* Build or return the field within the non-local frame state that holds
>> +/* Build or return the field within the non-local frame struct that holds
>>    the non-local goto "jmp_buf".  The buffer itself is maintained by the
>>    rtl middle-end as dynamic stack space is allocated.  */
>> 
>> @@ -1620,6 +1653,9 @@
>>   switch (TREE_CODE (t))
>>     {
>>     case ADDR_EXPR:
>> +      if (TREE_STATIC (t))
>> +    break;
>> +
>>       /* Build
>>        T.1 = &CHAIN->tramp;
>>        T.2 = __builtin_adjust_trampoline (T.1);
>> @@ -1714,6 +1750,22 @@
>>     }
>>       break;
>> 
>> +    case STATIC_CHAIN_EXPR:
>> +      decl = TREE_OPERAND (t, 0);
>> +      target_context = decl_function_context (decl);
>> +      if (target_context)
>> +    {
>> +      if (info->context == target_context)
>> +        {
>> +          /* Make sure frame_decl gets created.  */
>> +          (void) get_frame_type (info);
>> +        }
>> +      *tp = get_static_chain (info, target_context, &wi->tsi);
>> +    }
>> +      else
>> +    *tp = null_pointer_node;
>> +      break;
>> +
>>     case RETURN_EXPR:
>>     case GIMPLE_MODIFY_STMT:
>>     case WITH_SIZE_EXPR:
>> @@ -1768,13 +1820,22 @@
>>   return NULL_TREE;
>> }
>> 
>> +static bool
>> +debug_static_links (void)
>> +{ return
>> +    write_symbols != NO_DEBUG
>> +    && debug_info_level != DINFO_LEVEL_NONE
>> +    && debug_info_level != DINFO_LEVEL_TERSE;
>> +
>> +} /* debug_static_links */
>> +
>> /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>>    trampolines and call expressions.  On the way back up, determine if
>>    a nested function actually uses its static chain; if not, remember that.  */
>> 
>> static void
>> convert_all_function_calls (struct nesting_info *root)
>> -{
>> +{
>>   do
>>     {
>>       if (root->inner)
>> @@ -1784,7 +1845,10 @@
>>       walk_function (convert_call_expr, root);
>> 
>>       /* If the function does not use a static chain, then remember that.  */
>> -      if (root->outer && !root->chain_decl && !root->chain_field)
>> +      if (root->outer && !root->chain_decl && !root->chain_field
>> +/* REMOVE ME: */
>> +          /* && !debug_static_links () */
>> +         )
>>     DECL_NO_STATIC_CHAIN (root->context) = 1;
>>       else
>>     gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>> @@ -1806,6 +1870,21 @@
>>   tree context = root->context;
>>   struct function *sf;
>> 
>> +/* REMOVEME: */
>> +  /* If this is a nested function and we are supporting debugging via
>> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
>> +     chain, even if the programmer's code doesn't use it. */
>> +  if (false && root->outer && debug_static_links () )
>> +    { tree static_chain_decl, temp, stmt;
>> +      /* This is a desperate attempt to get later code generation to
>> +         store the static link.  If it works, it'll be a miracle. */
>> +      static_chain_decl = get_chain_decl (root);
>> +      stmt = build_addr (static_chain_decl, root->context);
>> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>> +      append_to_statement_list (stmt, &stmt_list);
>> +    }
>> +
>>   /* If we created a non-local frame type or decl, we need to lay them
>>      out at this time.  */
>>   if (root->frame_type)
>> @@ -1912,7 +1991,7 @@
>>      proper BIND_EXPR.  */
>>   if (root->new_local_var_chain)
>>     declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>> -          false);
>> +          true);
>>   if (root->debug_var_chain)
>>     declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>           true);
>> 
>> 
>> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed May 26 16:28:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 26 May 2010 10:28:51 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
Message-ID: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>

We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible.  The only thing is that we also build closures, so the trampoline mechanisms should be avoided.


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 26 May 2010, at 02:05, Jay K wrote:

> 
> Can any of this be removed?
> Can we really not just use "unfold-nested-procs" like NT386?
> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
> generally a considered the responsibility of optimizers.
> 
> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
> Maybe I'll try without.
> 
> 
> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
> 
> 
> -/* Build or return the RECORD_TYPE that describes the frame state that is
> -   shared between INFO->CONTEXT and its nested functions.  This record will
> -   not be complete until finalize_nesting_tree; up until that point we'll
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3-util.c */ 
> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec"; 
> +
> +/* Build or return the RECORD_TYPE that describes the non-local frame struct 
> +   that is shared between INFO->CONTEXT and its nested functions.  This record 
> +   will not be complete until finalize_nesting_tree; up until that point we'll
>     be adding fields as necessary.
>  
>     We also build the DECL that represents this frame in the function.  */
> @@ -209,7 +224,8 @@
>        free (name);
>  
>        info->frame_type = type;
> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
> +      info->frame_decl 
> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>  
>        /* ??? Always make it addressable for now, since it is meant to
>       be pointed to by the static chain pointer.  This pessimizes
> @@ -218,6 +234,8 @@
>       reachable, but the true pessimization is to create the non-
>       local frame structure in the first place.  */
>        TREE_ADDRESSABLE (info->frame_decl) = 1;
> +      /* m3gdb needs to know about this variable. */ 
> +      DECL_IGNORED_P (info->frame_decl) = 0;  
>      }
>    return type;
>  }
> @@ -290,6 +308,10 @@
>    return *slot;
>  }
>  
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */ 
> +static const char * static_link_var_name = "_static_link_var"; 
> +
>  /* Build or return the variable that holds the static chain within
>     INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>  
> @@ -310,9 +332,14 @@
>       Note also that it's represented as a parameter.  This is more
>       close to the truth, since the initial value does come from 
>       the caller.  */
> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
> +      decl = build_decl 
> +               (PARM_DECL, get_identifier (static_link_var_name), type);
> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */ 
>        DECL_ARTIFICIAL (decl) = 1;
> -      DECL_IGNORED_P (decl) = 1;
> +
> +      /* m3gdb needs to know about this variable. */ 
> +      DECL_IGNORED_P (decl) = 0;
> +
>        TREE_USED (decl) = 1;
>        DECL_CONTEXT (decl) = info->context;
>        DECL_ARG_TYPE (decl) = type;
> @@ -326,7 +353,11 @@
>    return decl;
>  }
>  
> -/* Build or return the field within the non-local frame state that holds
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */ 
> +static const char * static_link_copy_field_name = "_static_link_copy_field"; 
> +
> +/* Build or return the field within the non-local frame struct that holds
>     the static chain for INFO->CONTEXT.  This is the way to walk back up
>     multiple nesting levels.  */
>  
> @@ -339,10 +370,12 @@
>        tree type = build_pointer_type (get_frame_type (info->outer));
>  
>        field = make_node (FIELD_DECL);
> -      DECL_NAME (field) = get_identifier ("__chain");
> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>        TREE_TYPE (field) = type;
>        DECL_ALIGN (field) = TYPE_ALIGN (type);
>        DECL_NONADDRESSABLE_P (field) = 1;
> +      /* m3gdb should know about this field. */ 
> +      DECL_IGNORED_P (field) = 0;  
>  
>        insert_field_into_struct (get_frame_type (info), field);
>  
> @@ -465,7 +498,7 @@
>    return *slot;
>  } 
>  
> -/* Build or return the field within the non-local frame state that holds
> +/* Build or return the field within the non-local frame struct that holds
>     the non-local goto "jmp_buf".  The buffer itself is maintained by the
>     rtl middle-end as dynamic stack space is allocated.  */
>  
> @@ -1620,6 +1653,9 @@
>    switch (TREE_CODE (t))
>      {
>      case ADDR_EXPR:
> +      if (TREE_STATIC (t))
> +    break;
> +
>        /* Build
>         T.1 = &CHAIN->tramp;
>         T.2 = __builtin_adjust_trampoline (T.1);
> @@ -1714,6 +1750,22 @@
>      }
>        break;
>  
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
>      case RETURN_EXPR:
>      case GIMPLE_MODIFY_STMT:
>      case WITH_SIZE_EXPR:
> @@ -1768,13 +1820,22 @@
>    return NULL_TREE;
>  }
>  
> +static bool
> +debug_static_links (void) 
> +{ return
> +    write_symbols != NO_DEBUG
> +    && debug_info_level != DINFO_LEVEL_NONE
> +    && debug_info_level != DINFO_LEVEL_TERSE;
> +
> +} /* debug_static_links */ 
> +
>  /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>     trampolines and call expressions.  On the way back up, determine if
>     a nested function actually uses its static chain; if not, remember that.  */
>  
>  static void
>  convert_all_function_calls (struct nesting_info *root)
> -{
> +{ 
>    do
>      {
>        if (root->inner)
> @@ -1784,7 +1845,10 @@
>        walk_function (convert_call_expr, root);
>  
>        /* If the function does not use a static chain, then remember that.  */
> -      if (root->outer && !root->chain_decl && !root->chain_field)
> +      if (root->outer && !root->chain_decl && !root->chain_field
> +/* REMOVE ME: */ 
> +          /* && !debug_static_links () */ 
> +         )
>      DECL_NO_STATIC_CHAIN (root->context) = 1;
>        else
>      gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
> @@ -1806,6 +1870,21 @@
>    tree context = root->context;
>    struct function *sf;
>  
> +/* REMOVEME: */ 
> +  /* If this is a nested function and we are supporting debugging via
> +     m3gdb, we always need a chain_decl, so m3gdb can find the static 
> +     chain, even if the programmer's code doesn't use it. */ 
> +  if (false && root->outer && debug_static_links () )
> +    { tree static_chain_decl, temp, stmt;
> +      /* This is a desperate attempt to get later code generation to 
> +         store the static link.  If it works, it'll be a miracle. */ 
> +      static_chain_decl = get_chain_decl (root); 
> +      stmt = build_addr (static_chain_decl, root->context); 
> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
> +      append_to_statement_list (stmt, &stmt_list);
> +    } 
> +
>    /* If we created a non-local frame type or decl, we need to lay them
>       out at this time.  */
>    if (root->frame_type)
> @@ -1912,7 +1991,7 @@
>       proper BIND_EXPR.  */
>    if (root->new_local_var_chain)
>      declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
> -          false);
> +          true);
>    if (root->debug_var_chain)
>      declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>            true);
> 
> 
> 		 	   		  

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

From jay.krell at cornell.edu  Wed May 26 17:02:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 15:02:10 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
Message-ID: <COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>


> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 10:28:51 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
>
>
> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.


Right..for those that don't know..


There's no "good" efficient way to implement nested functions.
Our implementation is pretty "bad".
gcc's implementation is pretty "bad".
They are different.


gcc (Tony mentions "trampoline"):
In particular, taking the address of a nested function
involves runtime code generation on the stack.
These days, running code on the stack is "difficult".
On some systems, you do mprotect() to make that part of the stack executable.
On other systems, you just can't do it (iPhone).
On older systems, no problem. It is simple and efficient.


Modula-3:
Whenever we go to call a function pointer, we first see if it start with a 4 or 8 byte -1.
If so, it is our "closure" thingy, and the -1 is followed
I guess by an actual function pointer and a static link.
The static link is loaded wherever and the function called.


Other systems (see modern ATL on Windows) allocate executable
memory not on the stack. Not even regular heap is executable
generally any longer though, one need to VirtualAlloc or mmap or such.


This is a powerful mechanism in general, you can do stuff like
runtime "currying".


Pointers to nested Modula-3 function cannot be passed off
as function pointers to other languages.
? But hey, at least we can write nested functions and pass
??? them off to ourselves. Interop with C would just be bonus?


Calling function pointers in Modula-3 is slowed down
everywhere, in case the function pointer is nested.
I think.


-1 must be ensured to be invalid code.
Or we could make it a more visible part of porting.
?You know -- it could be per-target and folks would have
?to experiment with each target to find a good sequence,
?that is cheap to detect and guaranteed invalid.
?(ie: 0 might be better than -1!)


Could possibly replace the -1 with an actual function pointer
that is always called.
But then pointers to non-nested functions also wouldn't
interoperate with C.


I think there's something more to the mechanisms than I realize.
The "static link" must survive calls out to non-nested functions
or somesuch.


Anyway, while I think our mechanism is pretty clearly flawed,
it seems to be slightly less bad than gcc's.


Perhaps we should invest in what ATL does though and
dynamically allocate executable memory not on the stack?
Still, an "open" iPhone is probably better with the current scheme.
Most other systems should be ok either way.


I think there is a bit of 4.3=>4.5 that needs closer attention
and isn't obvious, this part:

+??? case STATIC_CHAIN_EXPR:
+????? decl = TREE_OPERAND (t, 0);
+????? target_context = decl_function_context (decl);
+????? if (target_context)
+??? {
+??? ? if (info->context == target_context)
+??? ??? {
+??? ????? /* Make sure frame_decl gets created.? */
+??? ????? (void) get_frame_type (info);
+??? ??? }
+??? ? *tp = get_static_chain (info, target_context, &wi->tsi);
+??? }
+????? else
+??? *tp = null_pointer_node;
+????? break;
+

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 17:13:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 15:13:38 +0000
Subject: [M3devel] closure marker
Message-ID: <COL101-W251CA496DF1BD58A8AEB48E6E90@phx.gbl>


As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
64bit systems that care about alignment pay quite a penality imho.


I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.


If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.


I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
? Do they have 4 byte instructions, that are always 4 byte aligned?


IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.


More general might be
? Target.ClosureElementSize? (bits)
? Target.ClosureElementCount? 


IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
Whereas most others would have Target.ClosureElementSize? = 32, Target.ClosureElementSize? = 1.
ClosureElementSize would be chosen to be match guaranteed code alignment.



? - Jay

 		 	   		  

From jay.krell at cornell.edu  Wed May 26 18:45:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 16:45:06 +0000
Subject: [M3devel] closure marker
Message-ID: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>


A little bit of research done (just searching the web):
?Mips, Alpha, PowerPC, HPPA, ARM, SPARC


all appear to use a 32bit instruction
presumably aligned but I couldn't confirm for all of them.
? It seems likely that if the processor cares about data alignment, then code will be aligned the same.


Looks like SH has 16bit instructions.


I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
With IA64 the expected exception with size=64bits, count=2.
? It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
? We can revisit at that time.
And really size=64, count=1 might suffice.

I'm a little torn.
A 64bit marker is more certain.
Code has been this way forever.
etc.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Subject: closure marker
> Date: Wed, 26 May 2010 15:13:38 +0000
>
>
> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
> 64bit systems that care about alignment pay quite a penality imho.
>
>
> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>
>
> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>
>
> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>   Do they have 4 byte instructions, that are always 4 byte aligned?
>
>
> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>
>
> More general might be
>   Target.ClosureElementSize  (bits)
>   Target.ClosureElementCount
>
>
> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
> Whereas most others would have Target.ClosureElementSize  = 32, Target.ClosureElementSize  = 1.
> ClosureElementSize would be chosen to be match guaranteed code alignment.
>
>
>
>   - Jay
>
>
 		 	   		  

From hendrik at topoi.pooq.com  Wed May 26 15:25:25 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 26 May 2010 09:25:25 -0400
Subject: [M3devel] OS for CM3
In-Reply-To: <729398.10895.qm@web23605.mail.ird.yahoo.com>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
	<729398.10895.qm@web23605.mail.ird.yahoo.com>
Message-ID: <20100526132524.GB18812@topoi.pooq.com>

On Tue, May 25, 2010 at 04:07:24AM +0000, Daniel Alejandro Benavides D. wrote:
> Hi:
> if easy of administration is what you are looking for maybe a bsd 
> flavour a is the right choice of use probably it would be a linux 
> distro but a common sense of easy administration and use like ubuntu 
> rh/centos server or why not a gentoo or archlinux if customization is 
> what you want to add more cores linux will support up to 1024 and the 
> small or medium size servers are commonly used in this servers sizes I 
> guess you have a good choice to take advantage, how many does support 
> Win server 2k3 (up to 64?) an another bsd up to how many?  
> 
> Hope it helps, thanks in advance

The next release of Debian is supposed to run on a BSD kernel as one of 
its platforms.  So there will be Linux and nonLinux distros for Debian.

-- hendrik


From hosking at cs.purdue.edu  Wed May 26 22:13:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 26 May 2010 16:13:29 -0400
Subject: [M3devel] DECL_LANG_SPECIFIC and casts?
In-Reply-To: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>
References: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>
Message-ID: <8EDE1A93-0507-43C2-8DF4-9291B1C4C8E4@cs.purdue.edu>

Why would this be problematic?  We need to retain it for later use, and I remember making sure that this worked.  Does the collector somehow delete the target?

On 26 May 2010, at 10:20, Jay K wrote:

> 
> Tony, this thing where we do:
> 
>   DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
> ...
> 
>       tree var = (tree)DECL_LANG_SPECIFIC(index);
> 
> 
> Is this running afoul of the gcc garbage collector?
>   Seems likely.
> 
> And does it matter?
>   Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
>  assuming m3_write_globals is called near the end.
> 
> 
> Thing is:
> struct lang_identifier GTY(()) ...
> union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
> struct lang_type GTY(()) ...
> typedef struct lang_decl GTY(()) ...
> struct language_function GTY(()) ...
> 
> 
> Which are nearly unused, cause me grief.
> They have to be different for 4.5 vs. 4.2/4.3.
>   Just the GTY needs to be moved to before the union/struct tag.
> 
> 
> I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
>   I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
>    aren't so small like ours so I'd rather not.
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Wed May 26 23:54:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 21:54:45 +0000
Subject: [M3devel] DECL_LANG_SPECIFIC and casts?
In-Reply-To: <8EDE1A93-0507-43C2-8DF4-9291B1C4C8E4@cs.purdue.edu>
References: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>,
	<8EDE1A93-0507-43C2-8DF4-9291B1C4C8E4@cs.purdue.edu>
Message-ID: <COL101-W43FC8D66C4B28F3CEC856AE6E90@phx.gbl>


Nevermind.
In 4.3 you have to say
struct foo GTY(())

in 4.5 you have to say struct GTY foo(());

Just on the type/field declarations.
Variables have the same syntax.

I asssume 4.2 matches 4.3 but I have to double check.

Apple, therefore iPhone, is still on 4.2.
I don't want to merge.
I'd rather keep 4.2/4.5 compatible code.

So if possible, would like to remove this stuff.
But doesn't seem possible.
Instead I'll move it to 4.2/4.5-specific files.

Unless by chance 4.2 is ok with the 4.5 form. 4.3 isn't.
Unfortunate.

? - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 16:13:29 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] DECL_LANG_SPECIFIC and casts?
>
> Why would this be problematic? We need to retain it for later use, and I remember making sure that this worked. Does the collector somehow delete the target?
>
> On 26 May 2010, at 10:20, Jay K wrote:
>
>>
>> Tony, this thing where we do:
>>
>> DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
>> ...
>>
>> tree var = (tree)DECL_LANG_SPECIFIC(index);
>>
>>
>> Is this running afoul of the gcc garbage collector?
>> Seems likely.
>>
>> And does it matter?
>> Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
>> assuming m3_write_globals is called near the end.
>>
>>
>> Thing is:
>> struct lang_identifier GTY(()) ...
>> union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
>> struct lang_type GTY(()) ...
>> typedef struct lang_decl GTY(()) ...
>> struct language_function GTY(()) ...
>>
>>
>> Which are nearly unused, cause me grief.
>> They have to be different for 4.5 vs. 4.2/4.3.
>> Just the GTY needs to be moved to before the union/struct tag.
>>
>>
>> I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
>> I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
>> aren't so small like ours so I'd rather not.
>>
>>
>> - Jay
>>
>
 		 	   		  

From rodney_bates at lcwb.coop  Thu May 27 00:37:07 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 17:37:07 -0500
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>
Message-ID: <4BFDA293.9080503@lcwb.coop>

I left it in because it is a work in progress.  I *really* want to get it to
work, and I don't what to have to reinvent what is already there when I get
to it.  I use nested procedures extensively in certain situations, and good
debugger support of them is important to me.  It all works fine on older code
generators than the gcc that added tree-nested.c.

Jay K wrote:
> Rodney, you added this function, along with a comment that says it doesn't actually work.
> Does it work?
> Does it accomplish anything?
> Can I remove it and its calls?
> 
> /* Special-purpose function to write stabs for the static_chain_decl. 
>    So far, this is not working.  m3gdb needs the place in the activation
>    record where the SL is stored.  Right now, the SL is not necessarily
>    stored at all, but may just be kept in a register.  DECL_RTL and 
>    DECL_INCOMING_RTL may both have register expressions.  But stabs
>    entries for register variables, of kind N_RSYM, are currently ignored
>    by gdb in dbxread.c, and making it read them could create problems
>    elsewhere, because there can be other variables for which both an
>    N_RSYM and an N_LSYM stabs entry are created.   
> */ 
> static int 
> dbxout_static_chain_decl (tree decl) 
> 
> It was added 19 months ago by:
>   http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
> 
> as well, do we need the #if 0 code added then?
> 
>  - Jay
>  		 	   		  


From jay.krell at cornell.edu  Thu May 27 00:53:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 22:53:24 +0000
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <4BFDA293.9080503@lcwb.coop>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>,
	<4BFDA293.9080503@lcwb.coop>
Message-ID: <COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>


Rodney, When you get back to it, can you just dig it out of history?
 
 
I still think we should try to avoid gcc's nested function functionality.
 
 
Where you use the static chain, not using the nested function functionality should
"automatically" be debuggable -- "automatic" as in, once the work is done
in the frontend to transform out nesting.
 
 
"debuggable" as in, you could follow the links yourself in the debugger.
The debugger need not search lexically nested functions that have function
calls dividing them.
 
 
?
 
 
There's stuff I still need to understand better -- particularly the affect of nested functions
on non-nested functions. Is there *always* an extra parameter to *all* functions?
It appears so.
And I haven't figured out how to merge with 4.5 what I think achieves that.
 
 
Maybe a good test of test cases here?
 
 
 
 - Jay


----------------------------------------
> Date: Wed, 26 May 2010 17:37:07 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
> I left it in because it is a work in progress. I *really* want to get it to
> work, and I don't what to have to reinvent what is already there when I get
> to it. I use nested procedures extensively in certain situations, and good
> debugger support of them is important to me. It all works fine on older code
> generators than the gcc that added tree-nested.c.
>
> Jay K wrote:
>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>> Does it work?
>> Does it accomplish anything?
>> Can I remove it and its calls?
>>
>> /* Special-purpose function to write stabs for the static_chain_decl.
>> So far, this is not working. m3gdb needs the place in the activation
>> record where the SL is stored. Right now, the SL is not necessarily
>> stored at all, but may just be kept in a register. DECL_RTL and
>> DECL_INCOMING_RTL may both have register expressions. But stabs
>> entries for register variables, of kind N_RSYM, are currently ignored
>> by gdb in dbxread.c, and making it read them could create problems
>> elsewhere, because there can be other variables for which both an
>> N_RSYM and an N_LSYM stabs entry are created.
>> */
>> static int
>> dbxout_static_chain_decl (tree decl)
>>
>> It was added 19 months ago by:
>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>
>> as well, do we need the #if 0 code added then?
>>
>> - Jay
>> 		 	   		  

From rodney_bates at lcwb.coop  Thu May 27 01:04:42 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 18:04:42 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>
Message-ID: <4BFDA90A.3050105@lcwb.coop>



Jay K wrote:
>> From: hosking at cs.purdue.edu
>> Date: Wed, 26 May 2010 10:28:51 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>>
>>
>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, 

whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
> 
> 
> Right..for those that don't know..
> 
> 
> There's no "good" efficient way to implement nested functions.
> Our implementation is pretty "bad".
> gcc's implementation is pretty "bad".

I think this is far too critical.  The inefficiencies you see are
minor.  Certainly no worse than the implementation of dispatching
methods of objects, something the world is gaga about.  And the
inefficiencies I think you are worrying about only arise when
you pass procedures as parameters.




> They are different.
> 
> 
> gcc (Tony mentions "trampoline"):
> In particular, taking the address of a nested function
> involves runtime code generation on the stack.
> These days, running code on the stack is "difficult".
> On some systems, you do mprotect() to make that part of the stack executable.
> On other systems, you just can't do it (iPhone).
> On older systems, no problem. It is simple and efficient.
> 

Yes, that is one consequence of trampolines.  There has to be a place
to generate code at runtime that will be executable, and a way to
memory-manage it.

> 
> Modula-3:
> Whenever we go to call a function pointer, we first see if it start with a 4 or 8 byte -1.
> If so, it is our "closure" thingy, and the -1 is followed
> I guess by an actual function pointer and a static link.
> The static link is loaded wherever and the function called.
> 
> 
> Other systems (see modern ATL on Windows) allocate executable
> memory not on the stack. Not even regular heap is executable
> generally any longer though, one need to VirtualAlloc or mmap or such.
> 
> 
> This is a powerful mechanism in general, you can do stuff like
> runtime "currying".
> 
> 
> Pointers to nested Modula-3 function cannot be passed off
> as function pointers to other languages.
>   But hey, at least we can write nested functions and pass
>     them off to ourselves. Interop with C would just be bonus?
> 

But if we used trampolines instead of our form of closures, they
could be.  Or, more generally, if we used the same mechanism as
"other languages", they could be.

> 
> Calling function pointers in Modula-3 is slowed down
> everywhere, in case the function pointer is nested.
> I think.

Only calling procedures through a procedure-typed _parameter_ is
slowed down.  Calling through a procedure-typed _variable_ is known,
by language semantics, always to be to a top-level procedure, and
is as fast as a C call to a non-nested function pointer.
Note that, when calling a function pointer to a nested procedure,
trampolines are surely about as fast as you can get.

> 
> 
> -1 must be ensured to be invalid code.
> Or we could make it a more visible part of porting.
>  You know -- it could be per-target and folks would have
>  to experiment with each target to find a good sequence,
>  that is cheap to detect and guaranteed invalid.
>  (ie: 0 might be better than -1!)
> 
> 
> Could possibly replace the -1 with an actual function pointer
> that is always called.
> But then pointers to non-nested functions also wouldn't
> interoperate with C.

I don't understand what mechanism you are proposing here.  Taken
literally, it sounds like a trampoline to me, which would allow
non-nested and nested function pointers to interoperate with C.

> 
> 
> I think there's something more to the mechanisms than I realize.
> The "static link" must survive calls out to non-nested functions
> or somesuch.
> 
> 
> Anyway, while I think our mechanism is pretty clearly flawed,
> it seems to be slightly less bad than gcc's.
> 

I'm not sure what you mean by flawed, but if you mean it doesn't
correctly implement language semantics, that is not true.  It works
correctly.  So do trampolines, although in C (for other reasons that
are independent of what mechanism you use for function pointers),
the semantics of the language have a big hole.  As usual, C passes
the buck by defining this as "undefined".

> 
> Perhaps we should invest in what ATL does though and
> dynamically allocate executable memory not on the stack?

If there is a way to do this, then trampolines can be made to work.
What does gcc do now on such targets?

> Still, an "open" iPhone is probably better with the current scheme.
> Most other systems should be ok either way.
> 
> 
> I think there is a bit of 4.3=>4.5 that needs closer attention
> and isn't obvious, this part:
> 
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
> 
>  - Jay
>  

Jay, you have made it clear repeatedly that you only use gdb, and
never m3gdb, so obviously, Modula-3-specific support is of no importance
to you.  That's OK, but please don't spoil the game for those of us
who do care about it by ripping stuff out of the compiler that m3gdb
needs.  Even when it isn't fully working yet.

		 	   		


From jay.krell at cornell.edu  Thu May 27 00:56:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 22:56:19 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>
References: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>,
	<88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>
Message-ID: <COL101-W50960886C3E99F184DBA1CE6E90@phx.gbl>


>> Nested functions should be transformed to not be nested. Imho.
 
> I don't understand this. Nested functions must be nested in the sense that
> they have static chain information provided by gcc.
 
 
 
Can it be achieved by adding an extra parameter instead?
 
 
 
>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
> What do you mean by this?
 
 
 
It looks like we inhibit optimization if -g is specified.
Like we preserve unused static chains.
This is has been discussed and I have to look at the code more..
Generating debug information should not inhibit optimization.
 
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 10:26:32 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
> On 26 May 2010, at 03:55, Jay K wrote:
>
>>
>> I'm going to try to keep the code that seems to do anything, however:
>>
>> 1) if (false &&
>>
>> I plan to remove that.
>>
>>
>> 2)
>> + if (root->outer && !root->chain_decl && !root->chain_field
>> +/* REMOVE ME: */
>> + /* && !debug_static_links () */
>> + )
>>
>>
>> I can't find where that would apply, and it is commented out anyway so I'll remove it.
>>
>>
>> I'm open to arguments though. :)
>>
>> dbxout.c
>> +#if 0
>> +/* Code copied from 1.4.2.2: */
>>
>>
>> I can cheaply enough keep that...should we really though?
>>
>>
>> I really think we can reduce our changes.
>> Enough type information should be passed around so that regular gdb works. Imho.
>
> Possibly, but M3 has a very different notion of type to C. Moreover, it is extremely valuable to have the M3 type ids there so that functionality can map back to the types in the M3 runtime system. It would be possible to implement much of the m3gdb debugging support by calling back into the language run-time passing the language type ids instead of relying on hand-crafted C in m3gdb. But I agree that more type information would be good, particularly for records.
>
>> And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
>> don't cause internal compiler errors. So that debug info might be generated on systems
>> that don't support stabs though granted they are few and minor (hppa64-hpux).
>> Nested functions should be transformed to not be nested. Imho.
>
> I don't understand this. Nested functions must be nested in the sense that they have static chain information provided by gcc.
>
>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
>
> What do you mean by this?
>
>>
>>
>> I realize the type information getting around is probably a lot of work.
>> And it is needed in m3back also, and probably not shared work.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: m3cc static chain stuff
>>> Date: Wed, 26 May 2010 06:05:25 +0000
>>>
>>>
>>> Can any of this be removed?
>>> Can we really not just use "unfold-nested-procs" like NT386?
>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>> generally a considered the responsibility of optimizers.
>>>
>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>> Maybe I'll try without.
>>>
>>>
>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>
>>>
>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> + m3-util.c */
>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>> +
>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>> be adding fields as necessary.
>>>
>>> We also build the DECL that represents this frame in the function. */
>>> @@ -209,7 +224,8 @@
>>> free (name);
>>>
>>> info->frame_type = type;
>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>> + info->frame_decl
>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>
>>> /* ??? Always make it addressable for now, since it is meant to
>>> be pointed to by the static chain pointer. This pessimizes
>>> @@ -218,6 +234,8 @@
>>> reachable, but the true pessimization is to create the non-
>>> local frame structure in the first place. */
>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>> + /* m3gdb needs to know about this variable. */
>>> + DECL_IGNORED_P (info->frame_decl) = 0;
>>> }
>>> return type;
>>> }
>>> @@ -290,6 +308,10 @@
>>> return *slot;
>>> }
>>>
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> + m3_util.c */
>>> +static const char * static_link_var_name = "_static_link_var";
>>> +
>>> /* Build or return the variable that holds the static chain within
>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>
>>> @@ -310,9 +332,14 @@
>>> Note also that it's represented as a parameter. This is more
>>> close to the truth, since the initial value does come from
>>> the caller. */
>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>> + decl = build_decl
>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>> DECL_ARTIFICIAL (decl) = 1;
>>> - DECL_IGNORED_P (decl) = 1;
>>> +
>>> + /* m3gdb needs to know about this variable. */
>>> + DECL_IGNORED_P (decl) = 0;
>>> +
>>> TREE_USED (decl) = 1;
>>> DECL_CONTEXT (decl) = info->context;
>>> DECL_ARG_TYPE (decl) = type;
>>> @@ -326,7 +353,11 @@
>>> return decl;
>>> }
>>>
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> + m3_util.c */
>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>> +
>>> +/* Build or return the field within the non-local frame struct that holds
>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>> multiple nesting levels. */
>>>
>>> @@ -339,10 +370,12 @@
>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>
>>> field = make_node (FIELD_DECL);
>>> - DECL_NAME (field) = get_identifier ("__chain");
>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>> TREE_TYPE (field) = type;
>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>> DECL_NONADDRESSABLE_P (field) = 1;
>>> + /* m3gdb should know about this field. */
>>> + DECL_IGNORED_P (field) = 0;
>>>
>>> insert_field_into_struct (get_frame_type (info), field);
>>>
>>> @@ -465,7 +498,7 @@
>>> return *slot;
>>> }
>>>
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* Build or return the field within the non-local frame struct that holds
>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>> rtl middle-end as dynamic stack space is allocated. */
>>>
>>> @@ -1620,6 +1653,9 @@
>>> switch (TREE_CODE (t))
>>> {
>>> case ADDR_EXPR:
>>> + if (TREE_STATIC (t))
>>> + break;
>>> +
>>> /* Build
>>> T.1 = &CHAIN->tramp;
>>> T.2 = __builtin_adjust_trampoline (T.1);
>>> @@ -1714,6 +1750,22 @@
>>> }
>>> break;
>>>
>>> + case STATIC_CHAIN_EXPR:
>>> + decl = TREE_OPERAND (t, 0);
>>> + target_context = decl_function_context (decl);
>>> + if (target_context)
>>> + {
>>> + if (info->context == target_context)
>>> + {
>>> + /* Make sure frame_decl gets created. */
>>> + (void) get_frame_type (info);
>>> + }
>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>> + }
>>> + else
>>> + *tp = null_pointer_node;
>>> + break;
>>> +
>>> case RETURN_EXPR:
>>> case GIMPLE_MODIFY_STMT:
>>> case WITH_SIZE_EXPR:
>>> @@ -1768,13 +1820,22 @@
>>> return NULL_TREE;
>>> }
>>>
>>> +static bool
>>> +debug_static_links (void)
>>> +{ return
>>> + write_symbols != NO_DEBUG
>>> + && debug_info_level != DINFO_LEVEL_NONE
>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>> +
>>> +} /* debug_static_links */
>>> +
>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>> trampolines and call expressions. On the way back up, determine if
>>> a nested function actually uses its static chain; if not, remember that. */
>>>
>>> static void
>>> convert_all_function_calls (struct nesting_info *root)
>>> -{
>>> +{
>>> do
>>> {
>>> if (root->inner)
>>> @@ -1784,7 +1845,10 @@
>>> walk_function (convert_call_expr, root);
>>>
>>> /* If the function does not use a static chain, then remember that. */
>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>> +/* REMOVE ME: */
>>> + /* && !debug_static_links () */
>>> + )
>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>> else
>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>> @@ -1806,6 +1870,21 @@
>>> tree context = root->context;
>>> struct function *sf;
>>>
>>> +/* REMOVEME: */
>>> + /* If this is a nested function and we are supporting debugging via
>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>> + chain, even if the programmer's code doesn't use it. */
>>> + if (false && root->outer && debug_static_links () )
>>> + { tree static_chain_decl, temp, stmt;
>>> + /* This is a desperate attempt to get later code generation to
>>> + store the static link. If it works, it'll be a miracle. */
>>> + static_chain_decl = get_chain_decl (root);
>>> + stmt = build_addr (static_chain_decl, root->context);
>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>> + append_to_statement_list (stmt, &stmt_list);
>>> + }
>>> +
>>> /* If we created a non-local frame type or decl, we need to lay them
>>> out at this time. */
>>> if (root->frame_type)
>>> @@ -1912,7 +1991,7 @@
>>> proper BIND_EXPR. */
>>> if (root->new_local_var_chain)
>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>> - false);
>>> + true);
>>> if (root->debug_var_chain)
>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>> true);
>>>
>>>
>>>
>>
> 		 	   		  

From rodney_bates at lcwb.coop  Thu May 27 01:14:34 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 18:14:34 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
Message-ID: <4BFDAB5A.6000304@lcwb.coop>



Tony Hosking wrote:
> We should endeavour to use the same functionality that the C compiler 
> uses for its own nested functions, whereever possible.  The only thing 
> is that we also build closures, so the trampoline mechanisms should be 
> avoided.

I don't follow the last part of this argument.  If we follow the first
principle, we would just use trampolines, since they are the same
mechanism the C compiler uses.  And the only place they are not possible
are places where they won't work for C either (e.g., a target where there
is no place to construct code at runtime and have it be executable).
The mere fact that we "also build closures" is not a necessity, just
the reflection of the design decision to use the closure mechanism
instead of trampolines.

OTHO, despite all the positive things I have said here and in another post
about trampolines, I don't favor using them, because they would make m3gdb
support a lot more difficult.  m3gdb needs to be able to both read and
construct closures/trampolines, whichever.  Closures are almost target-
independent, except for the native word size, which is already easily
available to m3gdb.  Trampolines are going to be different for every
instruction set, and the ones constructed by compiled code, at least,
could even change with compiler version.  m3gdb would need a _lot_ of
highly target-dependent code to handle them.

> 
> 
> 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 26 May 2010, at 02:05, Jay K wrote:
> 
>>
>> Can any of this be removed?
>> Can we really not just use "unfold-nested-procs" like NT386?
>> We'd just lose a little bit of optimization, in rare cases, stop 
>> paying a bad cost/benefit ratio?
>> Part of this is actually *deoptimization*. If the compiler decides the 
>> values aren't used, then it should
>> be allowed to remove them. That is normal. Wanting to unused stuff in 
>> the debugger isn't
>> generally a considered the responsibility of optimizers.
>>
>> Therefore -- we could "unfold", remove our diffs, and gain some 
>> optimization and some deoptimization.
>> Maybe I'll try without.
>>
>>
>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c 
>> /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 
>> 09:36:43.000000000 -0800
>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 
>> 22:27:58.000000000 -0700
>>
>>
>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>> -   shared between INFO->CONTEXT and its nested functions.  This 
>> record will
>> -   not be complete until finalize_nesting_tree; up until that point we'll
>> +/* This must agree with the string defined by the same name in m3gdb, 
>> file
>> +   m3-util.c */
>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>> +
>> +/* Build or return the RECORD_TYPE that describes the non-local frame 
>> struct
>> +   that is shared between INFO->CONTEXT and its nested functions.  
>> This record
>> +   will not be complete until finalize_nesting_tree; up until that 
>> point we'll
>>     be adding fields as necessary.
>>  
>>     We also build the DECL that represents this frame in the function.  */
>> @@ -209,7 +224,8 @@
>>        free (name);
>>  
>>        info->frame_type = type;
>> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>> +      info->frame_decl
>> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>  
>>        /* ??? Always make it addressable for now, since it is meant to
>>       be pointed to by the static chain pointer.  This pessimizes
>> @@ -218,6 +234,8 @@
>>       reachable, but the true pessimization is to create the non-
>>       local frame structure in the first place.  */
>>        TREE_ADDRESSABLE (info->frame_decl) = 1;
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (info->frame_decl) = 0; 
>>      }
>>    return type;
>>  }
>> @@ -290,6 +308,10 @@
>>    return *slot;
>>  }
>>  
>> +/* This must agree with the string defined by the same name in m3gdb, 
>> file
>> +   m3_util.c */
>> +static const char * static_link_var_name = "_static_link_var";
>> +
>>  /* Build or return the variable that holds the static chain within
>>     INFO->CONTEXT.  This variable may only be used within 
>> INFO->CONTEXT.  */
>>  
>> @@ -310,9 +332,14 @@
>>       Note also that it's represented as a parameter.  This is more
>>       close to the truth, since the initial value does come from
>>       the caller.  */
>> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>> +      decl = build_decl
>> +               (PARM_DECL, get_identifier (static_link_var_name), type);
>> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout 
>> needs it. */
>>        DECL_ARTIFICIAL (decl) = 1;
>> -      DECL_IGNORED_P (decl) = 1;
>> +
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (decl) = 0;
>> +
>>        TREE_USED (decl) = 1;
>>        DECL_CONTEXT (decl) = info->context;
>>        DECL_ARG_TYPE (decl) = type;
>> @@ -326,7 +353,11 @@
>>    return decl;
>>  }
>>  
>> -/* Build or return the field within the non-local frame state that holds
>> +/* This must agree with the string defined by the same name in m3gdb, 
>> file
>> +   m3_util.c */
>> +static const char * static_link_copy_field_name = 
>> "_static_link_copy_field";
>> +
>> +/* Build or return the field within the non-local frame struct that holds
>>     the static chain for INFO->CONTEXT.  This is the way to walk back up
>>     multiple nesting levels.  */
>>  
>> @@ -339,10 +370,12 @@
>>        tree type = build_pointer_type (get_frame_type (info->outer));
>>  
>>        field = make_node (FIELD_DECL);
>> -      DECL_NAME (field) = get_identifier ("__chain");
>> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>        TREE_TYPE (field) = type;
>>        DECL_ALIGN (field) = TYPE_ALIGN (type);
>>        DECL_NONADDRESSABLE_P (field) = 1;
>> +      /* m3gdb should know about this field. */
>> +      DECL_IGNORED_P (field) = 0; 
>>  
>>        insert_field_into_struct (get_frame_type (info), field);
>>  
>> @@ -465,7 +498,7 @@
>>    return *slot;
>>  }
>>  
>> -/* Build or return the field within the non-local frame state that holds
>> +/* Build or return the field within the non-local frame struct that holds
>>     the non-local goto "jmp_buf".  The buffer itself is maintained by the
>>     rtl middle-end as dynamic stack space is allocated.  */
>>  
>> @@ -1620,6 +1653,9 @@
>>    switch (TREE_CODE (t))
>>      {
>>      case ADDR_EXPR:
>> +      if (TREE_STATIC (t))
>> +    break;
>> +
>>        /* Build
>>         T.1 = &CHAIN->tramp;
>>         T.2 = __builtin_adjust_trampoline (T.1);
>> @@ -1714,6 +1750,22 @@
>>      }
>>        break;
>>  
>> +    case STATIC_CHAIN_EXPR:
>> +      decl = TREE_OPERAND (t, 0);
>> +      target_context = decl_function_context (decl);
>> +      if (target_context)
>> +    {
>> +      if (info->context == target_context)
>> +        {
>> +          /* Make sure frame_decl gets created.  */
>> +          (void) get_frame_type (info);
>> +        }
>> +      *tp = get_static_chain (info, target_context, &wi->tsi);
>> +    }
>> +      else
>> +    *tp = null_pointer_node;
>> +      break;
>> +
>>      case RETURN_EXPR:
>>      case GIMPLE_MODIFY_STMT:
>>      case WITH_SIZE_EXPR:
>> @@ -1768,13 +1820,22 @@
>>    return NULL_TREE;
>>  }
>>  
>> +static bool
>> +debug_static_links (void)
>> +{ return
>> +    write_symbols != NO_DEBUG
>> +    && debug_info_level != DINFO_LEVEL_NONE
>> +    && debug_info_level != DINFO_LEVEL_TERSE;
>> +
>> +} /* debug_static_links */
>> +
>>  /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>>     trampolines and call expressions.  On the way back up, determine if
>>     a nested function actually uses its static chain; if not, remember 
>> that.  */
>>  
>>  static void
>>  convert_all_function_calls (struct nesting_info *root)
>> -{
>> +{
>>    do
>>      {
>>        if (root->inner)
>> @@ -1784,7 +1845,10 @@
>>        walk_function (convert_call_expr, root);
>>  
>>        /* If the function does not use a static chain, then remember 
>> that.  */
>> -      if (root->outer && !root->chain_decl && !root->chain_field)
>> +      if (root->outer && !root->chain_decl && !root->chain_field
>> +/* REMOVE ME: */
>> +          /* && !debug_static_links () */
>> +         )
>>      DECL_NO_STATIC_CHAIN (root->context) = 1;
>>        else
>>      gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>> @@ -1806,6 +1870,21 @@
>>    tree context = root->context;
>>    struct function *sf;
>>  
>> +/* REMOVEME: */
>> +  /* If this is a nested function and we are supporting debugging via
>> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
>> +     chain, even if the programmer's code doesn't use it. */
>> +  if (false && root->outer && debug_static_links () )
>> +    { tree static_chain_decl, temp, stmt;
>> +      /* This is a desperate attempt to get later code generation to
>> +         store the static link.  If it works, it'll be a miracle. */
>> +      static_chain_decl = get_chain_decl (root);
>> +      stmt = build_addr (static_chain_decl, root->context);
>> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), 
>> NULL);
>> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>> +      append_to_statement_list (stmt, &stmt_list);
>> +    }
>> +
>>    /* If we created a non-local frame type or decl, we need to lay them
>>       out at this time.  */
>>    if (root->frame_type)
>> @@ -1912,7 +1991,7 @@
>>       proper BIND_EXPR.  */
>>    if (root->new_local_var_chain)
>>      declare_vars (root->new_local_var_chain, DECL_SAVED_TREE 
>> (root->context),
>> -          false);
>> +          true);
>>    if (root->debug_var_chain)
>>      declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>            true);
>>
>>
>>     
> 


From rodney_bates at lcwb.coop  Thu May 27 01:20:38 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 18:20:38 -0500
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>
Message-ID: <4BFDACC6.6020600@lcwb.coop>

After the marker, a closure also has two pointers, one to executable code,
and one to an environment of nonlocal variables.  These will always have
to be aligned to whatever pointers require on the target.  So making the
marker smaller than a native pointer would then require padding the
closure to get the pointers aligned.  This uses as much space as just
keeping the marker word-sized.

And no, I don't think it makes any sense to (on a 64-bit target) start
a closure on an odd multiple of 4 bytes, just so you can make the marker
smaller while keeping the following pointers word-aligned.

Jay K wrote:
> A little bit of research done (just searching the web):
>  Mips, Alpha, PowerPC, HPPA, ARM, SPARC
> 
> 
> all appear to use a 32bit instruction
> presumably aligned but I couldn't confirm for all of them.
>   It seems likely that if the processor cares about data alignment, then code will be aligned the same.
> 
> 
> Looks like SH has 16bit instructions.
> 
> 
> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
> With IA64 the expected exception with size=64bits, count=2.
>   It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>   We can revisit at that time.
> And really size=64, count=1 might suffice.
> 
> I'm a little torn.
> A 64bit marker is more certain.
> Code has been this way forever.
> etc.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>> Subject: closure marker
>> Date: Wed, 26 May 2010 15:13:38 +0000
>>
>>
>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>> 64bit systems that care about alignment pay quite a penality imho.
>>
>>
>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>
>>
>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>
>>
>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>   Do they have 4 byte instructions, that are always 4 byte aligned?
>>
>>
>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>
>>
>> More general might be
>>   Target.ClosureElementSize  (bits)
>>   Target.ClosureElementCount
>>
>>
>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>> Whereas most others would have Target.ClosureElementSize  = 32, Target.ClosureElementSize  = 1.
>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>
>>
>>
>>   - Jay
>>
>>
>  		 	   		  


From jay.krell at cornell.edu  Thu May 27 01:27:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 23:27:11 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <4BFDA90A.3050105@lcwb.coop>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>, ,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>
Message-ID: <COL101-W555E980AF6D3E51F8224B6E6E90@phx.gbl>


Rodney, if it doesn't work at all, and hasn't been worked on in a while, it should probably be removed.
If it works sometimes, ok.
If it say if (false) or #if 0, then it can be removed.
 If enabling that code provides something that sometimes work, why don't we just enable it always?
 Does it sometimes crash or have other bad properties?
 
 
I'm not just removing stuff, I'm also merging with 4.5.
The more we have, the more there is to merge.
Anything to reduce that work, even if it isn't huge in the first place, is good.
 [hypocrisy by me here]
 Dead code bears increasing cost, as we merge with more versions.
 
 
As well, if we are ever to be a gcc "plugin", we can't have any diffs. 
  "gcc plugin" is a new 4.5 feature.
I'm not sure this is a goal or viable, granted.
 
 
 
I don't like waiting for m3gdb to build and it isn't supported on some platforms e.g. Darwin.
I do want to see my data, but I'm skeptical it should require much or any changes to the debugger.
Esp. given that the changes to the compiler are pretty small.
Partly this is leftover from when I used Cygwin more -- everything (involving fork) is slow there.
 
 
 
There is part of the code that doesn't appear to be just about debugging and doesn't merge obviously.
The code it is in has been changed a lot, to iterate over a different form of data.
That I need I think I need to understand.
It appears, I think, that every single function call in Modula-3 has its codegen altered.
 Not just through pointers.
 It appears that way, and that is also my read of the m3back code, though I haven't yet looked at the generated code to confirm...and all my stepping through code in the past..I never noticed.
 
 
 
> Only calling procedures through a procedure-typed _parameter_ is
> slowed down. Calling through a procedure-typed _variable_ is known,

 
 Why are parameters different than variables?
 Can't I store a parameter in a variable? Even a local one? 
 Maybe not, because that might have bad "lifetime" and bad "safety"?
 
 
 
 Isn't every call through a function pointer affected?
 
 
What ATL does, you would call a "trampoline", but it isn't stored on the stack.
They call VirtualAlloc() which among the read/write flags includes an executable flag.
  At least on newer versions of Windows.
Since VirtualAlloc is expensive, as well as VirtualAlloc allocating in 64K chunk and the trampolines being small, a cache is maintained, as well as a presumably a sub-allocator being employed.
 
 
(If you think about it, you realize that there has *always* been some way to do this -- the linker writes a file and that file is executable. It could be "temporary", need not ever hit the disk.)
 
 
 - Jay



----------------------------------------
> Date: Wed, 26 May 2010 18:04:42 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
>
>
> Jay K wrote:
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>
>>>
>>>
>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions,
>
> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>
>>
>> Right..for those that don't know..
>>
>>
>> There's no "good" efficient way to implement nested functions.
>> Our implementation is pretty "bad".
>> gcc's implementation is pretty "bad".
>
> I think this is far too critical. The inefficiencies you see are
> minor. Certainly no worse than the implementation of dispatching
> methods of objects, something the world is gaga about. And the
> inefficiencies I think you are worrying about only arise when
> you pass procedures as parameters.
>
>
>
>
>> They are different.
>>
>>
>> gcc (Tony mentions "trampoline"):
>> In particular, taking the address of a nested function
>> involves runtime code generation on the stack.
>> These days, running code on the stack is "difficult".
>> On some systems, you do mprotect() to make that part of the stack executable.
>> On other systems, you just can't do it (iPhone).
>> On older systems, no problem. It is simple and efficient.
>>
>
> Yes, that is one consequence of trampolines. There has to be a place
> to generate code at runtime that will be executable, and a way to
> memory-manage it.
>
>>
>> Modula-3:
>> Whenever we go to call a function pointer, we first see if it start with a 4 or 8 byte -1.
>> If so, it is our "closure" thingy, and the -1 is followed
>> I guess by an actual function pointer and a static link.
>> The static link is loaded wherever and the function called.
>>
>>
>> Other systems (see modern ATL on Windows) allocate executable
>> memory not on the stack. Not even regular heap is executable
>> generally any longer though, one need to VirtualAlloc or mmap or such.
>>
>>
>> This is a powerful mechanism in general, you can do stuff like
>> runtime "currying".
>>
>>
>> Pointers to nested Modula-3 function cannot be passed off
>> as function pointers to other languages.
>> But hey, at least we can write nested functions and pass
>> them off to ourselves. Interop with C would just be bonus?
>>
>
> But if we used trampolines instead of our form of closures, they
> could be. Or, more generally, if we used the same mechanism as
> "other languages", they could be.
>
>>
>> Calling function pointers in Modula-3 is slowed down
>> everywhere, in case the function pointer is nested.
>> I think.
>
> Only calling procedures through a procedure-typed _parameter_ is
> slowed down. Calling through a procedure-typed _variable_ is known,
> by language semantics, always to be to a top-level procedure, and
> is as fast as a C call to a non-nested function pointer.
> Note that, when calling a function pointer to a nested procedure,
> trampolines are surely about as fast as you can get.
>
>>
>>
>> -1 must be ensured to be invalid code.
>> Or we could make it a more visible part of porting.
>> You know -- it could be per-target and folks would have
>> to experiment with each target to find a good sequence,
>> that is cheap to detect and guaranteed invalid.
>> (ie: 0 might be better than -1!)
>>
>>
>> Could possibly replace the -1 with an actual function pointer
>> that is always called.
>> But then pointers to non-nested functions also wouldn't
>> interoperate with C.
>
> I don't understand what mechanism you are proposing here. Taken
> literally, it sounds like a trampoline to me, which would allow
> non-nested and nested function pointers to interoperate with C.
>
>>
>>
>> I think there's something more to the mechanisms than I realize.
>> The "static link" must survive calls out to non-nested functions
>> or somesuch.
>>
>>
>> Anyway, while I think our mechanism is pretty clearly flawed,
>> it seems to be slightly less bad than gcc's.
>>
>
> I'm not sure what you mean by flawed, but if you mean it doesn't
> correctly implement language semantics, that is not true. It works
> correctly. So do trampolines, although in C (for other reasons that
> are independent of what mechanism you use for function pointers),
> the semantics of the language have a big hole. As usual, C passes
> the buck by defining this as "undefined".
>
>>
>> Perhaps we should invest in what ATL does though and
>> dynamically allocate executable memory not on the stack?
>
> If there is a way to do this, then trampolines can be made to work.
> What does gcc do now on such targets?
>
>> Still, an "open" iPhone is probably better with the current scheme.
>> Most other systems should be ok either way.
>>
>>
>> I think there is a bit of 4.3=>4.5 that needs closer attention
>> and isn't obvious, this part:
>>
>> + case STATIC_CHAIN_EXPR:
>> + decl = TREE_OPERAND (t, 0);
>> + target_context = decl_function_context (decl);
>> + if (target_context)
>> + {
>> + if (info->context == target_context)
>> + {
>> + /* Make sure frame_decl gets created. */
>> + (void) get_frame_type (info);
>> + }
>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>> + }
>> + else
>> + *tp = null_pointer_node;
>> + break;
>> +
>>
>> - Jay
>>
>
> Jay, you have made it clear repeatedly that you only use gdb, and
> never m3gdb, so obviously, Modula-3-specific support is of no importance
> to you. That's OK, but please don't spoil the game for those of us
> who do care about it by ripping stuff out of the compiler that m3gdb
> needs. Even when it isn't fully working yet.
>
> 		 	   		  

From jay.krell at cornell.edu  Thu May 27 01:38:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 23:38:09 +0000
Subject: [M3devel] closure marker
In-Reply-To: <4BFDACC6.6020600@lcwb.coop>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>,
	<4BFDACC6.6020600@lcwb.coop>
Message-ID: <COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>


Rodney, It's not a data size optimization. It is a code size optimization.
Adding the padding is ok.
 
 
 
See Aligned_procedures use in.
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
 
PROCEDURE If_closure (proc: Val;  true, false: Label;  freq: Frequency) =
  VAR skip := Next_label ();  nope := skip;
  BEGIN
    IF (false # No_label) THEN  nope := false; END;
    IF NOT Target.Aligned_procedures THEN
      Push (proc);
      Force ();
      cg.loophole (Type.Addr, Target.Integer.cg_type);
      Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
      cg.and (Target.Integer.cg_type);
      cg.if_true (Target.Integer.cg_type, nope, Always - freq);
      SPop (1, "If_closure-unaligned");
    END;
    Push (proc);
    Boost_alignment (Target.Address.align);
    Force ();
    cg.load_nil ();
    cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
    Push (proc);
    Boost_alignment (Target.Integer.align);
    Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
    Push_int (M3RT.CL_marker_value);
    IF (true # No_label)
      THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
      ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
    END;
    Set_label (skip);
    SPop (2, "If_closure");
  END If_closure;
 
 
Aligned_procedures would become effectively always true.
Code would be reduced.
 
 
I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
 
 
 - Jay



----------------------------------------
> Date: Wed, 26 May 2010 18:20:38 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
> After the marker, a closure also has two pointers, one to executable code,
> and one to an environment of nonlocal variables. These will always have
> to be aligned to whatever pointers require on the target. So making the
> marker smaller than a native pointer would then require padding the
> closure to get the pointers aligned. This uses as much space as just
> keeping the marker word-sized.
>
> And no, I don't think it makes any sense to (on a 64-bit target) start
> a closure on an odd multiple of 4 bytes, just so you can make the marker
> smaller while keeping the following pointers word-aligned.
>
> Jay K wrote:
>> A little bit of research done (just searching the web):
>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>
>>
>> all appear to use a 32bit instruction
>> presumably aligned but I couldn't confirm for all of them.
>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>
>>
>> Looks like SH has 16bit instructions.
>>
>>
>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>> With IA64 the expected exception with size=64bits, count=2.
>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>> We can revisit at that time.
>> And really size=64, count=1 might suffice.
>>
>> I'm a little torn.
>> A 64bit marker is more certain.
>> Code has been this way forever.
>> etc.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>> Subject: closure marker
>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>
>>>
>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>> 64bit systems that care about alignment pay quite a penality imho.
>>>
>>>
>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>
>>>
>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>
>>>
>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>
>>>
>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>
>>>
>>> More general might be
>>> Target.ClosureElementSize (bits)
>>> Target.ClosureElementCount
>>>
>>>
>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>> 		 	   		  

From mika at async.async.caltech.edu  Thu May 27 02:11:33 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 26 May 2010 17:11:33 -0700
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W555E980AF6D3E51F8224B6E6E90@phx.gbl> 
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>, ,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>
	<COL101-W555E980AF6D3E51F8224B6E6E90@phx.gbl>
Message-ID: <20100527001133.7A5831A207D@async.async.caltech.edu>

Jay K writes:
...
>=20
> Why are parameters different than variables?
> Can't I store a parameter in a variable? Even a local one?=20
> Maybe not=2C because that might have bad "lifetime" and bad "safety"?
...

No you can't assign a procedure parameter that came from an inner
procedure to a variable.

In the below example, the activation record for A is already destroyed
when I call b().  It's still there in C.

TYPE P = PROCEDURE();

VAR a,b : P;

PROCEDURE A() =

  PROCEDURE B() = BEGIN END B;

  PROCEDURE C(p : P) = BEGIN p() END C;

  BEGIN
    C(B);   (* OK *)
    b := B; (* BAD! *)
  END A;

BEGIN
  a := A;
  a(); (* OK *)
  b(); (* ERROR *)
END.

The runtime does check for this.  It aborts at (* BAD! *)

  
    Mika


From hosking at cs.purdue.edu  Thu May 27 11:27:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 05:27:56 -0400
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>,
	<4BFDA293.9080503@lcwb.coop>
	<COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>
Message-ID: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>

Argh!!!!!
No!  We don't want to do work in the front-end to get rid of nesting.
It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.



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 26 May 2010, at 18:53, Jay K wrote:

> 
> Rodney, When you get back to it, can you just dig it out of history?
> 
> 
> I still think we should try to avoid gcc's nested function functionality.
> 
> 
> Where you use the static chain, not using the nested function functionality should
> "automatically" be debuggable -- "automatic" as in, once the work is done
> in the frontend to transform out nesting.
> 
> 
> "debuggable" as in, you could follow the links yourself in the debugger.
> The debugger need not search lexically nested functions that have function
> calls dividing them.
> 
> 
> ?
> 
> 
> There's stuff I still need to understand better -- particularly the affect of nested functions
> on non-nested functions. Is there *always* an extra parameter to *all* functions?
> It appears so.
> And I haven't figured out how to merge with 4.5 what I think achieves that.
> 
> 
> Maybe a good test of test cases here?
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> Date: Wed, 26 May 2010 17:37:07 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>> 
>> I left it in because it is a work in progress. I *really* want to get it to
>> work, and I don't what to have to reinvent what is already there when I get
>> to it. I use nested procedures extensively in certain situations, and good
>> debugger support of them is important to me. It all works fine on older code
>> generators than the gcc that added tree-nested.c.
>> 
>> Jay K wrote:
>>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>>> Does it work?
>>> Does it accomplish anything?
>>> Can I remove it and its calls?
>>> 
>>> /* Special-purpose function to write stabs for the static_chain_decl.
>>> So far, this is not working. m3gdb needs the place in the activation
>>> record where the SL is stored. Right now, the SL is not necessarily
>>> stored at all, but may just be kept in a register. DECL_RTL and
>>> DECL_INCOMING_RTL may both have register expressions. But stabs
>>> entries for register variables, of kind N_RSYM, are currently ignored
>>> by gdb in dbxread.c, and making it read them could create problems
>>> elsewhere, because there can be other variables for which both an
>>> N_RSYM and an N_LSYM stabs entry are created.
>>> */
>>> static int
>>> dbxout_static_chain_decl (tree decl)
>>> 
>>> It was added 19 months ago by:
>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>> 
>>> as well, do we need the #if 0 code added then?
>>> 
>>> - Jay
>>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu May 27 11:32:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 05:32:19 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W50960886C3E99F184DBA1CE6E90@phx.gbl>
References: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>,
	<88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>
	<COL101-W50960886C3E99F184DBA1CE6E90@phx.gbl>
Message-ID: <2329B0DA-0FA5-4C74-9C12-A0CDFE35BADE@cs.purdue.edu>



On 26 May 2010, at 18:56, Jay K wrote:

> 
>>> Nested functions should be transformed to not be nested. Imho.
> 
>> I don't understand this. Nested functions must be nested in the sense that
>> they have static chain information provided by gcc.
> 
> 
> 
> Can it be achieved by adding an extra parameter instead?

The compiler *does* (inside gcc) add an extra parameter.

> 
> 
>>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
>> What do you mean by this?
> 
> 
> 
> It looks like we inhibit optimization if -g is specified.
> Like we preserve unused static chains.
> This is has been discussed and I have to look at the code more..
> Generating debug information should not inhibit optimisation.

Generating debug information inhibits optimisations where sufficient state needs to be kept around to support symbolic debugging.  I don't think it inhibits optimisation in any way we care about.

> 
> 
> 
> - Jay
> 
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 26 May 2010 10:26:32 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>> 
>> On 26 May 2010, at 03:55, Jay K wrote:
>> 
>>> 
>>> I'm going to try to keep the code that seems to do anything, however:
>>> 
>>> 1) if (false &&
>>> 
>>> I plan to remove that.
>>> 
>>> 
>>> 2)
>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>> +/* REMOVE ME: */
>>> + /* && !debug_static_links () */
>>> + )
>>> 
>>> 
>>> I can't find where that would apply, and it is commented out anyway so I'll remove it.
>>> 
>>> 
>>> I'm open to arguments though. :)
>>> 
>>> dbxout.c
>>> +#if 0
>>> +/* Code copied from 1.4.2.2: */
>>> 
>>> 
>>> I can cheaply enough keep that...should we really though?
>>> 
>>> 
>>> I really think we can reduce our changes.
>>> Enough type information should be passed around so that regular gdb works. Imho.
>> 
>> Possibly, but M3 has a very different notion of type to C. Moreover, it is extremely valuable to have the M3 type ids there so that functionality can map back to the types in the M3 runtime system. It would be possible to implement much of the m3gdb debugging support by calling back into the language run-time passing the language type ids instead of relying on hand-crafted C in m3gdb. But I agree that more type information would be good, particularly for records.
>> 
>>> And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
>>> don't cause internal compiler errors. So that debug info might be generated on systems
>>> that don't support stabs though granted they are few and minor (hppa64-hpux).
>>> Nested functions should be transformed to not be nested. Imho.
>> 
>> I don't understand this. Nested functions must be nested in the sense that they have static chain information provided by gcc.
>> 
>>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
>> 
>> What do you mean by this?
>> 
>>> 
>>> 
>>> I realize the type information getting around is probably a lot of work.
>>> And it is needed in m3back also, and probably not shared work.
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Subject: m3cc static chain stuff
>>>> Date: Wed, 26 May 2010 06:05:25 +0000
>>>> 
>>>> 
>>>> Can any of this be removed?
>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>> generally a considered the responsibility of optimizers.
>>>> 
>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>> Maybe I'll try without.
>>>> 
>>>> 
>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>> 
>>>> 
>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3-util.c */
>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>> +
>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>> be adding fields as necessary.
>>>> 
>>>> We also build the DECL that represents this frame in the function. */
>>>> @@ -209,7 +224,8 @@
>>>> free (name);
>>>> 
>>>> info->frame_type = type;
>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>> + info->frame_decl
>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>> 
>>>> /* ??? Always make it addressable for now, since it is meant to
>>>> be pointed to by the static chain pointer. This pessimizes
>>>> @@ -218,6 +234,8 @@
>>>> reachable, but the true pessimization is to create the non-
>>>> local frame structure in the first place. */
>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (info->frame_decl) = 0;
>>>> }
>>>> return type;
>>>> }
>>>> @@ -290,6 +308,10 @@
>>>> return *slot;
>>>> }
>>>> 
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_var_name = "_static_link_var";
>>>> +
>>>> /* Build or return the variable that holds the static chain within
>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>> 
>>>> @@ -310,9 +332,14 @@
>>>> Note also that it's represented as a parameter. This is more
>>>> close to the truth, since the initial value does come from
>>>> the caller. */
>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>> + decl = build_decl
>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>> DECL_ARTIFICIAL (decl) = 1;
>>>> - DECL_IGNORED_P (decl) = 1;
>>>> +
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (decl) = 0;
>>>> +
>>>> TREE_USED (decl) = 1;
>>>> DECL_CONTEXT (decl) = info->context;
>>>> DECL_ARG_TYPE (decl) = type;
>>>> @@ -326,7 +353,11 @@
>>>> return decl;
>>>> }
>>>> 
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>> +
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>> multiple nesting levels. */
>>>> 
>>>> @@ -339,10 +370,12 @@
>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>> 
>>>> field = make_node (FIELD_DECL);
>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>> TREE_TYPE (field) = type;
>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>> + /* m3gdb should know about this field. */
>>>> + DECL_IGNORED_P (field) = 0;
>>>> 
>>>> insert_field_into_struct (get_frame_type (info), field);
>>>> 
>>>> @@ -465,7 +498,7 @@
>>>> return *slot;
>>>> }
>>>> 
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>> rtl middle-end as dynamic stack space is allocated. */
>>>> 
>>>> @@ -1620,6 +1653,9 @@
>>>> switch (TREE_CODE (t))
>>>> {
>>>> case ADDR_EXPR:
>>>> + if (TREE_STATIC (t))
>>>> + break;
>>>> +
>>>> /* Build
>>>> T.1 = &CHAIN->tramp;
>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>> @@ -1714,6 +1750,22 @@
>>>> }
>>>> break;
>>>> 
>>>> + case STATIC_CHAIN_EXPR:
>>>> + decl = TREE_OPERAND (t, 0);
>>>> + target_context = decl_function_context (decl);
>>>> + if (target_context)
>>>> + {
>>>> + if (info->context == target_context)
>>>> + {
>>>> + /* Make sure frame_decl gets created. */
>>>> + (void) get_frame_type (info);
>>>> + }
>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>> + }
>>>> + else
>>>> + *tp = null_pointer_node;
>>>> + break;
>>>> +
>>>> case RETURN_EXPR:
>>>> case GIMPLE_MODIFY_STMT:
>>>> case WITH_SIZE_EXPR:
>>>> @@ -1768,13 +1820,22 @@
>>>> return NULL_TREE;
>>>> }
>>>> 
>>>> +static bool
>>>> +debug_static_links (void)
>>>> +{ return
>>>> + write_symbols != NO_DEBUG
>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>> +
>>>> +} /* debug_static_links */
>>>> +
>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>> trampolines and call expressions. On the way back up, determine if
>>>> a nested function actually uses its static chain; if not, remember that. */
>>>> 
>>>> static void
>>>> convert_all_function_calls (struct nesting_info *root)
>>>> -{
>>>> +{
>>>> do
>>>> {
>>>> if (root->inner)
>>>> @@ -1784,7 +1845,10 @@
>>>> walk_function (convert_call_expr, root);
>>>> 
>>>> /* If the function does not use a static chain, then remember that. */
>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>> +/* REMOVE ME: */
>>>> + /* && !debug_static_links () */
>>>> + )
>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>> else
>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>> @@ -1806,6 +1870,21 @@
>>>> tree context = root->context;
>>>> struct function *sf;
>>>> 
>>>> +/* REMOVEME: */
>>>> + /* If this is a nested function and we are supporting debugging via
>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>> + chain, even if the programmer's code doesn't use it. */
>>>> + if (false && root->outer && debug_static_links () )
>>>> + { tree static_chain_decl, temp, stmt;
>>>> + /* This is a desperate attempt to get later code generation to
>>>> + store the static link. If it works, it'll be a miracle. */
>>>> + static_chain_decl = get_chain_decl (root);
>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>> + append_to_statement_list (stmt, &stmt_list);
>>>> + }
>>>> +
>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>> out at this time. */
>>>> if (root->frame_type)
>>>> @@ -1912,7 +1991,7 @@
>>>> proper BIND_EXPR. */
>>>> if (root->new_local_var_chain)
>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>> - false);
>>>> + true);
>>>> if (root->debug_var_chain)
>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>> true);
>>>> 
>>>> 
>>>> 
>>> 
>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu May 27 11:33:52 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 05:33:52 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <4BFDAB5A.6000304@lcwb.coop>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
	<4BFDAB5A.6000304@lcwb.coop>
Message-ID: <D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>

The trampoline mechanism is broken on many platforms because they disable executable stacks.  I strongly favour retaining the current mechanisms.

On 26 May 2010, at 19:14, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible.  The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
> 
> I don't follow the last part of this argument.  If we follow the first
> principle, we would just use trampolines, since they are the same
> mechanism the C compiler uses.  And the only place they are not possible
> are places where they won't work for C either (e.g., a target where there
> is no place to construct code at runtime and have it be executable).
> The mere fact that we "also build closures" is not a necessity, just
> the reflection of the design decision to use the closure mechanism
> instead of trampolines.
> 
> OTHO, despite all the positive things I have said here and in another post
> about trampolines, I don't favor using them, because they would make m3gdb
> support a lot more difficult.  m3gdb needs to be able to both read and
> construct closures/trampolines, whichever.  Closures are almost target-
> independent, except for the native word size, which is already easily
> available to m3gdb.  Trampolines are going to be different for every
> instruction set, and the ones constructed by compiled code, at least,
> could even change with compiler version.  m3gdb would need a _lot_ of
> highly target-dependent code to handle them.
> 
>> 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 26 May 2010, at 02:05, Jay K wrote:
>>> 
>>> Can any of this be removed?
>>> Can we really not just use "unfold-nested-procs" like NT386?
>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>> generally a considered the responsibility of optimizers.
>>> 
>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>> Maybe I'll try without.
>>> 
>>> 
>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
>>> 
>>> 
>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>> -   shared between INFO->CONTEXT and its nested functions.  This record will
>>> -   not be complete until finalize_nesting_tree; up until that point we'll
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> +   m3-util.c */
>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>> +
>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>> +   that is shared between INFO->CONTEXT and its nested functions.  This record
>>> +   will not be complete until finalize_nesting_tree; up until that point we'll
>>>    be adding fields as necessary.
>>>     We also build the DECL that represents this frame in the function.  */
>>> @@ -209,7 +224,8 @@
>>>       free (name);
>>>        info->frame_type = type;
>>> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>> +      info->frame_decl
>>> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>        /* ??? Always make it addressable for now, since it is meant to
>>>      be pointed to by the static chain pointer.  This pessimizes
>>> @@ -218,6 +234,8 @@
>>>      reachable, but the true pessimization is to create the non-
>>>      local frame structure in the first place.  */
>>>       TREE_ADDRESSABLE (info->frame_decl) = 1;
>>> +      /* m3gdb needs to know about this variable. */
>>> +      DECL_IGNORED_P (info->frame_decl) = 0;      }
>>>   return type;
>>> }
>>> @@ -290,6 +308,10 @@
>>>   return *slot;
>>> }
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> +   m3_util.c */
>>> +static const char * static_link_var_name = "_static_link_var";
>>> +
>>> /* Build or return the variable that holds the static chain within
>>>    INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>>> @@ -310,9 +332,14 @@
>>>      Note also that it's represented as a parameter.  This is more
>>>      close to the truth, since the initial value does come from
>>>      the caller.  */
>>> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>> +      decl = build_decl
>>> +               (PARM_DECL, get_identifier (static_link_var_name), type);
>>> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>       DECL_ARTIFICIAL (decl) = 1;
>>> -      DECL_IGNORED_P (decl) = 1;
>>> +
>>> +      /* m3gdb needs to know about this variable. */
>>> +      DECL_IGNORED_P (decl) = 0;
>>> +
>>>       TREE_USED (decl) = 1;
>>>       DECL_CONTEXT (decl) = info->context;
>>>       DECL_ARG_TYPE (decl) = type;
>>> @@ -326,7 +353,11 @@
>>>   return decl;
>>> }
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> +   m3_util.c */
>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>> +
>>> +/* Build or return the field within the non-local frame struct that holds
>>>    the static chain for INFO->CONTEXT.  This is the way to walk back up
>>>    multiple nesting levels.  */
>>> @@ -339,10 +370,12 @@
>>>       tree type = build_pointer_type (get_frame_type (info->outer));
>>>        field = make_node (FIELD_DECL);
>>> -      DECL_NAME (field) = get_identifier ("__chain");
>>> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>       TREE_TYPE (field) = type;
>>>       DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>       DECL_NONADDRESSABLE_P (field) = 1;
>>> +      /* m3gdb should know about this field. */
>>> +      DECL_IGNORED_P (field) = 0;         insert_field_into_struct (get_frame_type (info), field);
>>> @@ -465,7 +498,7 @@
>>>   return *slot;
>>> }
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* Build or return the field within the non-local frame struct that holds
>>>    the non-local goto "jmp_buf".  The buffer itself is maintained by the
>>>    rtl middle-end as dynamic stack space is allocated.  */
>>> @@ -1620,6 +1653,9 @@
>>>   switch (TREE_CODE (t))
>>>     {
>>>     case ADDR_EXPR:
>>> +      if (TREE_STATIC (t))
>>> +    break;
>>> +
>>>       /* Build
>>>        T.1 = &CHAIN->tramp;
>>>        T.2 = __builtin_adjust_trampoline (T.1);
>>> @@ -1714,6 +1750,22 @@
>>>     }
>>>       break;
>>> +    case STATIC_CHAIN_EXPR:
>>> +      decl = TREE_OPERAND (t, 0);
>>> +      target_context = decl_function_context (decl);
>>> +      if (target_context)
>>> +    {
>>> +      if (info->context == target_context)
>>> +        {
>>> +          /* Make sure frame_decl gets created.  */
>>> +          (void) get_frame_type (info);
>>> +        }
>>> +      *tp = get_static_chain (info, target_context, &wi->tsi);
>>> +    }
>>> +      else
>>> +    *tp = null_pointer_node;
>>> +      break;
>>> +
>>>     case RETURN_EXPR:
>>>     case GIMPLE_MODIFY_STMT:
>>>     case WITH_SIZE_EXPR:
>>> @@ -1768,13 +1820,22 @@
>>>   return NULL_TREE;
>>> }
>>> +static bool
>>> +debug_static_links (void)
>>> +{ return
>>> +    write_symbols != NO_DEBUG
>>> +    && debug_info_level != DINFO_LEVEL_NONE
>>> +    && debug_info_level != DINFO_LEVEL_TERSE;
>>> +
>>> +} /* debug_static_links */
>>> +
>>> /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>>>    trampolines and call expressions.  On the way back up, determine if
>>>    a nested function actually uses its static chain; if not, remember that.  */
>>>  static void
>>> convert_all_function_calls (struct nesting_info *root)
>>> -{
>>> +{
>>>   do
>>>     {
>>>       if (root->inner)
>>> @@ -1784,7 +1845,10 @@
>>>       walk_function (convert_call_expr, root);
>>>        /* If the function does not use a static chain, then remember that.  */
>>> -      if (root->outer && !root->chain_decl && !root->chain_field)
>>> +      if (root->outer && !root->chain_decl && !root->chain_field
>>> +/* REMOVE ME: */
>>> +          /* && !debug_static_links () */
>>> +         )
>>>     DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>       else
>>>     gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>> @@ -1806,6 +1870,21 @@
>>>   tree context = root->context;
>>>   struct function *sf;
>>> +/* REMOVEME: */
>>> +  /* If this is a nested function and we are supporting debugging via
>>> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
>>> +     chain, even if the programmer's code doesn't use it. */
>>> +  if (false && root->outer && debug_static_links () )
>>> +    { tree static_chain_decl, temp, stmt;
>>> +      /* This is a desperate attempt to get later code generation to
>>> +         store the static link.  If it works, it'll be a miracle. */
>>> +      static_chain_decl = get_chain_decl (root);
>>> +      stmt = build_addr (static_chain_decl, root->context);
>>> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>> +      append_to_statement_list (stmt, &stmt_list);
>>> +    }
>>> +
>>>   /* If we created a non-local frame type or decl, we need to lay them
>>>      out at this time.  */
>>>   if (root->frame_type)
>>> @@ -1912,7 +1991,7 @@
>>>      proper BIND_EXPR.  */
>>>   if (root->new_local_var_chain)
>>>     declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>> -          false);
>>> +          true);
>>>   if (root->debug_var_chain)
>>>     declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>           true);
>>> 
>>> 
>>>    



From jay.krell at cornell.edu  Thu May 27 13:27:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 11:27:44 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
Message-ID: <col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>


I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
 
 
I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
  Because it has a similar but inferior mechanism.
 
 
One wonders about Ada though -- does it supported nested functions?
  I noticed it bears a striking resembles to Pascal/Modula-3. :)
 
And uses the same not great trampoline mechanism?
 
 
If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
Those are two very big ifs.
 
 
Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?
Ah.
We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
 
                             -- pointer to function --
                             -- parameter/static chain whatever --
 trampoline points here =>   -- start of code --
                             -- target dependent position independent not very optimized
                             -- *constant* hand crafted code that fetchs the data from just before itself
 
 
Would that address the m3gdb problem?
 Putting the data at fixed negative offsets from the trampoline code?
 Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
  to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
 
 
Granted, crafting that code would be.. fun. :)
Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 05:33:52 -0400
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>
> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>
>>
>>
>> Tony Hosking wrote:
>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>
>> I don't follow the last part of this argument. If we follow the first
>> principle, we would just use trampolines, since they are the same
>> mechanism the C compiler uses. And the only place they are not possible
>> are places where they won't work for C either (e.g., a target where there
>> is no place to construct code at runtime and have it be executable).
>> The mere fact that we "also build closures" is not a necessity, just
>> the reflection of the design decision to use the closure mechanism
>> instead of trampolines.
>>
>> OTHO, despite all the positive things I have said here and in another post
>> about trampolines, I don't favor using them, because they would make m3gdb
>> support a lot more difficult. m3gdb needs to be able to both read and
>> construct closures/trampolines, whichever. Closures are almost target-
>> independent, except for the native word size, which is already easily
>> available to m3gdb. Trampolines are going to be different for every
>> instruction set, and the ones constructed by compiled code, at least,
>> could even change with compiler version. m3gdb would need a _lot_ of
>> highly target-dependent code to handle them.
>>
>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>
>>>> Can any of this be removed?
>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>> generally a considered the responsibility of optimizers.
>>>>
>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>> Maybe I'll try without.
>>>>
>>>>
>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>
>>>>
>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3-util.c */
>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>> +
>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>> be adding fields as necessary.
>>>> We also build the DECL that represents this frame in the function. */
>>>> @@ -209,7 +224,8 @@
>>>> free (name);
>>>> info->frame_type = type;
>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>> + info->frame_decl
>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>> /* ??? Always make it addressable for now, since it is meant to
>>>> be pointed to by the static chain pointer. This pessimizes
>>>> @@ -218,6 +234,8 @@
>>>> reachable, but the true pessimization is to create the non-
>>>> local frame structure in the first place. */
>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>> return type;
>>>> }
>>>> @@ -290,6 +308,10 @@
>>>> return *slot;
>>>> }
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_var_name = "_static_link_var";
>>>> +
>>>> /* Build or return the variable that holds the static chain within
>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>> @@ -310,9 +332,14 @@
>>>> Note also that it's represented as a parameter. This is more
>>>> close to the truth, since the initial value does come from
>>>> the caller. */
>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>> + decl = build_decl
>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>> DECL_ARTIFICIAL (decl) = 1;
>>>> - DECL_IGNORED_P (decl) = 1;
>>>> +
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (decl) = 0;
>>>> +
>>>> TREE_USED (decl) = 1;
>>>> DECL_CONTEXT (decl) = info->context;
>>>> DECL_ARG_TYPE (decl) = type;
>>>> @@ -326,7 +353,11 @@
>>>> return decl;
>>>> }
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>> +
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>> multiple nesting levels. */
>>>> @@ -339,10 +370,12 @@
>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>> field = make_node (FIELD_DECL);
>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>> TREE_TYPE (field) = type;
>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>> + /* m3gdb should know about this field. */
>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>> @@ -465,7 +498,7 @@
>>>> return *slot;
>>>> }
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>> rtl middle-end as dynamic stack space is allocated. */
>>>> @@ -1620,6 +1653,9 @@
>>>> switch (TREE_CODE (t))
>>>> {
>>>> case ADDR_EXPR:
>>>> + if (TREE_STATIC (t))
>>>> + break;
>>>> +
>>>> /* Build
>>>> T.1 = &CHAIN->tramp;
>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>> @@ -1714,6 +1750,22 @@
>>>> }
>>>> break;
>>>> + case STATIC_CHAIN_EXPR:
>>>> + decl = TREE_OPERAND (t, 0);
>>>> + target_context = decl_function_context (decl);
>>>> + if (target_context)
>>>> + {
>>>> + if (info->context == target_context)
>>>> + {
>>>> + /* Make sure frame_decl gets created. */
>>>> + (void) get_frame_type (info);
>>>> + }
>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>> + }
>>>> + else
>>>> + *tp = null_pointer_node;
>>>> + break;
>>>> +
>>>> case RETURN_EXPR:
>>>> case GIMPLE_MODIFY_STMT:
>>>> case WITH_SIZE_EXPR:
>>>> @@ -1768,13 +1820,22 @@
>>>> return NULL_TREE;
>>>> }
>>>> +static bool
>>>> +debug_static_links (void)
>>>> +{ return
>>>> + write_symbols != NO_DEBUG
>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>> +
>>>> +} /* debug_static_links */
>>>> +
>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>> trampolines and call expressions. On the way back up, determine if
>>>> a nested function actually uses its static chain; if not, remember that. */
>>>> static void
>>>> convert_all_function_calls (struct nesting_info *root)
>>>> -{
>>>> +{
>>>> do
>>>> {
>>>> if (root->inner)
>>>> @@ -1784,7 +1845,10 @@
>>>> walk_function (convert_call_expr, root);
>>>> /* If the function does not use a static chain, then remember that. */
>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>> +/* REMOVE ME: */
>>>> + /* && !debug_static_links () */
>>>> + )
>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>> else
>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>> @@ -1806,6 +1870,21 @@
>>>> tree context = root->context;
>>>> struct function *sf;
>>>> +/* REMOVEME: */
>>>> + /* If this is a nested function and we are supporting debugging via
>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>> + chain, even if the programmer's code doesn't use it. */
>>>> + if (false && root->outer && debug_static_links () )
>>>> + { tree static_chain_decl, temp, stmt;
>>>> + /* This is a desperate attempt to get later code generation to
>>>> + store the static link. If it works, it'll be a miracle. */
>>>> + static_chain_decl = get_chain_decl (root);
>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>> + append_to_statement_list (stmt, &stmt_list);
>>>> + }
>>>> +
>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>> out at this time. */
>>>> if (root->frame_type)
>>>> @@ -1912,7 +1991,7 @@
>>>> proper BIND_EXPR. */
>>>> if (root->new_local_var_chain)
>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>> - false);
>>>> + true);
>>>> if (root->debug_var_chain)
>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>> true);
>>>>
>>>>
>>>>
> 		 	   		  

From jay.krell at cornell.edu  Thu May 27 13:31:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 11:31:20 +0000
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>, ,
	<4BFDA293.9080503@lcwb.coop>,
	<COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>,
	<665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
Message-ID: <COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>


Shouldn't gcc be able to optimize about as well any such transform?
  Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
 
Anyway, ok.
 
There's stuff I have to figure out and understand here either way.
 
Like, does the the static chain "flow" through non-nested calls?
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 05:27:56 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
>
>
> Argh!!!!!
> No! We don't want to do work in the front-end to get rid of nesting.
> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>
>
>
>
> 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 26 May 2010, at 18:53, Jay K wrote:
>
>
> Rodney, When you get back to it, can you just dig it out of history?
>
>
> I still think we should try to avoid gcc's nested function functionality.
>
>
> Where you use the static chain, not using the nested function functionality should
> "automatically" be debuggable -- "automatic" as in, once the work is done
> in the frontend to transform out nesting.
>
>
> "debuggable" as in, you could follow the links yourself in the debugger.
> The debugger need not search lexically nested functions that have function
> calls dividing them.
>
>
> ?
>
>
> There's stuff I still need to understand better -- particularly the affect of nested functions
> on non-nested functions. Is there *always* an extra parameter to *all* functions?
> It appears so.
> And I haven't figured out how to merge with 4.5 what I think achieves that.
>
>
> Maybe a good test of test cases here?
>
>
>
> - Jay
>
>
> ----------------------------------------
> Date: Wed, 26 May 2010 17:37:07 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
> I left it in because it is a work in progress. I *really* want to get it to
> work, and I don't what to have to reinvent what is already there when I get
> to it. I use nested procedures extensively in certain situations, and good
> debugger support of them is important to me. It all works fine on older code
> generators than the gcc that added tree-nested.c.
>
> Jay K wrote:
> Rodney, you added this function, along with a comment that says it doesn't actually work.
> Does it work?
> Does it accomplish anything?
> Can I remove it and its calls?
>
> /* Special-purpose function to write stabs for the static_chain_decl.
> So far, this is not working. m3gdb needs the place in the activation
> record where the SL is stored. Right now, the SL is not necessarily
> stored at all, but may just be kept in a register. DECL_RTL and
> DECL_INCOMING_RTL may both have register expressions. But stabs
> entries for register variables, of kind N_RSYM, are currently ignored
> by gdb in dbxread.c, and making it read them could create problems
> elsewhere, because there can be other variables for which both an
> N_RSYM and an N_LSYM stabs entry are created.
> */
> static int
> dbxout_static_chain_decl (tree decl)
>
> It was added 19 months ago by:
> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>
> as well, do we need the #if 0 code added then?
>
> - Jay
>
> 		 	   		  

From hosking at cs.purdue.edu  Thu May 27 14:10:50 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 08:10:50 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
	<col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
Message-ID: <BC008F6B-61C8-481A-9927-2B23DC6D6909@cs.purdue.edu>

m3gdb doesn't read trampolines because the gcc-based backend does not generate them!


On 27 May 2010, at 07:27, Jay K wrote:

> 
> I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
> 
> 
> I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
>  Because it has a similar but inferior mechanism.
> 
> 
> One wonders about Ada though -- does it supported nested functions?
>  I noticed it bears a striking resembles to Pascal/Modula-3. :)
> 
> And uses the same not great trampoline mechanism?
> 
> 
> If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
> Those are two very big ifs.
> 
> 
> Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?
> Ah.
> We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
> 
>                             -- pointer to function --
>                             -- parameter/static chain whatever --
> trampoline points here =>   -- start of code --
>                             -- target dependent position independent not very optimized
>                             -- *constant* hand crafted code that fetchs the data from just before itself
> 
> 
> Would that address the m3gdb problem?
> Putting the data at fixed negative offsets from the trampoline code?
> Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
>  to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
> 
> 
> Granted, crafting that code would be.. fun. :)
> Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:33:52 -0400
>> To: rodney_bates at lcwb.coop
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>> 
>> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>> 
>> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>> 
>>> 
>>> 
>>> Tony Hosking wrote:
>>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>> 
>>> I don't follow the last part of this argument. If we follow the first
>>> principle, we would just use trampolines, since they are the same
>>> mechanism the C compiler uses. And the only place they are not possible
>>> are places where they won't work for C either (e.g., a target where there
>>> is no place to construct code at runtime and have it be executable).
>>> The mere fact that we "also build closures" is not a necessity, just
>>> the reflection of the design decision to use the closure mechanism
>>> instead of trampolines.
>>> 
>>> OTHO, despite all the positive things I have said here and in another post
>>> about trampolines, I don't favor using them, because they would make m3gdb
>>> support a lot more difficult. m3gdb needs to be able to both read and
>>> construct closures/trampolines, whichever. Closures are almost target-
>>> independent, except for the native word size, which is already easily
>>> available to m3gdb. Trampolines are going to be different for every
>>> instruction set, and the ones constructed by compiled code, at least,
>>> could even change with compiler version. m3gdb would need a _lot_ of
>>> highly target-dependent code to handle them.
>>> 
>>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>> 
>>>>> Can any of this be removed?
>>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>>> generally a considered the responsibility of optimizers.
>>>>> 
>>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>>> Maybe I'll try without.
>>>>> 
>>>>> 
>>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>> 
>>>>> 
>>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3-util.c */
>>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>>> +
>>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>>> be adding fields as necessary.
>>>>> We also build the DECL that represents this frame in the function. */
>>>>> @@ -209,7 +224,8 @@
>>>>> free (name);
>>>>> info->frame_type = type;
>>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>>> + info->frame_decl
>>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>>> /* ??? Always make it addressable for now, since it is meant to
>>>>> be pointed to by the static chain pointer. This pessimizes
>>>>> @@ -218,6 +234,8 @@
>>>>> reachable, but the true pessimization is to create the non-
>>>>> local frame structure in the first place. */
>>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>>> return type;
>>>>> }
>>>>> @@ -290,6 +308,10 @@
>>>>> return *slot;
>>>>> }
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_var_name = "_static_link_var";
>>>>> +
>>>>> /* Build or return the variable that holds the static chain within
>>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>>> @@ -310,9 +332,14 @@
>>>>> Note also that it's represented as a parameter. This is more
>>>>> close to the truth, since the initial value does come from
>>>>> the caller. */
>>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>>> + decl = build_decl
>>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>>> DECL_ARTIFICIAL (decl) = 1;
>>>>> - DECL_IGNORED_P (decl) = 1;
>>>>> +
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (decl) = 0;
>>>>> +
>>>>> TREE_USED (decl) = 1;
>>>>> DECL_CONTEXT (decl) = info->context;
>>>>> DECL_ARG_TYPE (decl) = type;
>>>>> @@ -326,7 +353,11 @@
>>>>> return decl;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>>> +
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>>> multiple nesting levels. */
>>>>> @@ -339,10 +370,12 @@
>>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>>> field = make_node (FIELD_DECL);
>>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>>> TREE_TYPE (field) = type;
>>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>>> + /* m3gdb should know about this field. */
>>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>>> @@ -465,7 +498,7 @@
>>>>> return *slot;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>>> rtl middle-end as dynamic stack space is allocated. */
>>>>> @@ -1620,6 +1653,9 @@
>>>>> switch (TREE_CODE (t))
>>>>> {
>>>>> case ADDR_EXPR:
>>>>> + if (TREE_STATIC (t))
>>>>> + break;
>>>>> +
>>>>> /* Build
>>>>> T.1 = &CHAIN->tramp;
>>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>>> @@ -1714,6 +1750,22 @@
>>>>> }
>>>>> break;
>>>>> + case STATIC_CHAIN_EXPR:
>>>>> + decl = TREE_OPERAND (t, 0);
>>>>> + target_context = decl_function_context (decl);
>>>>> + if (target_context)
>>>>> + {
>>>>> + if (info->context == target_context)
>>>>> + {
>>>>> + /* Make sure frame_decl gets created. */
>>>>> + (void) get_frame_type (info);
>>>>> + }
>>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>>> + }
>>>>> + else
>>>>> + *tp = null_pointer_node;
>>>>> + break;
>>>>> +
>>>>> case RETURN_EXPR:
>>>>> case GIMPLE_MODIFY_STMT:
>>>>> case WITH_SIZE_EXPR:
>>>>> @@ -1768,13 +1820,22 @@
>>>>> return NULL_TREE;
>>>>> }
>>>>> +static bool
>>>>> +debug_static_links (void)
>>>>> +{ return
>>>>> + write_symbols != NO_DEBUG
>>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>>> +
>>>>> +} /* debug_static_links */
>>>>> +
>>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>>> trampolines and call expressions. On the way back up, determine if
>>>>> a nested function actually uses its static chain; if not, remember that. */
>>>>> static void
>>>>> convert_all_function_calls (struct nesting_info *root)
>>>>> -{
>>>>> +{
>>>>> do
>>>>> {
>>>>> if (root->inner)
>>>>> @@ -1784,7 +1845,10 @@
>>>>> walk_function (convert_call_expr, root);
>>>>> /* If the function does not use a static chain, then remember that. */
>>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>>> +/* REMOVE ME: */
>>>>> + /* && !debug_static_links () */
>>>>> + )
>>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>>> else
>>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>>> @@ -1806,6 +1870,21 @@
>>>>> tree context = root->context;
>>>>> struct function *sf;
>>>>> +/* REMOVEME: */
>>>>> + /* If this is a nested function and we are supporting debugging via
>>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>>> + chain, even if the programmer's code doesn't use it. */
>>>>> + if (false && root->outer && debug_static_links () )
>>>>> + { tree static_chain_decl, temp, stmt;
>>>>> + /* This is a desperate attempt to get later code generation to
>>>>> + store the static link. If it works, it'll be a miracle. */
>>>>> + static_chain_decl = get_chain_decl (root);
>>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>>> + append_to_statement_list (stmt, &stmt_list);
>>>>> + }
>>>>> +
>>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>>> out at this time. */
>>>>> if (root->frame_type)
>>>>> @@ -1912,7 +1991,7 @@
>>>>> proper BIND_EXPR. */
>>>>> if (root->new_local_var_chain)
>>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>>> - false);
>>>>> + true);
>>>>> if (root->debug_var_chain)
>>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>>> true);
>>>>> 
>>>>> 
>>>>> 
>> 		 	   		  



From jay.krell at cornell.edu  Thu May 27 14:26:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 12:26:18 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <BC008F6B-61C8-481A-9927-2B23DC6D6909@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
	<col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>,
	<BC008F6B-61C8-481A-9927-2B23DC6D6909@cs.purdue.edu>
Message-ID: <COL101-W509A5F179B6BE9A4C4CD1FE6EA0@phx.gbl>


But, it reads closures?
And IF there was a reasonable portable "executable heap", and trampolines were put there..the debugability could be solved as described -- putting the parameter(s) at fixed negative offsets from the code?

?- Jay


----------------------------------------
> Subject: Re: [M3devel] m3cc static chain stuff
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 08:10:50 -0400
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> m3gdb doesn't read trampolines because the gcc-based backend does not generate them!
>
>
> On 27 May 2010, at 07:27, Jay K wrote:
>
>>
>> I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
>>
>>
>> I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
>> Because it has a similar but inferior mechanism.
>>
>>
>> One wonders about Ada though -- does it supported nested functions?
>> I noticed it bears a striking resembles to Pascal/Modula-3. :)
>>
>> And uses the same not great trampoline mechanism?
>>
>>
>> If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
>> Those are two very big ifs.
>>
>>
>> Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?
>> Ah.
>> We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
>>
>> -- pointer to function --
>> -- parameter/static chain whatever --
>> trampoline points here => -- start of code --
>> -- target dependent position independent not very optimized
>> -- *constant* hand crafted code that fetchs the data from just before itself
>>
>>
>> Would that address the m3gdb problem?
>> Putting the data at fixed negative offsets from the trampoline code?
>> Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
>> to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
>>
>>
>> Granted, crafting that code would be.. fun. :)
>> Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 27 May 2010 05:33:52 -0400
>>> To: rodney_bates at lcwb.coop
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>
>>> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>>>
>>> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>>>
>>>>
>>>>
>>>> Tony Hosking wrote:
>>>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> I don't follow the last part of this argument. If we follow the first
>>>> principle, we would just use trampolines, since they are the same
>>>> mechanism the C compiler uses. And the only place they are not possible
>>>> are places where they won't work for C either (e.g., a target where there
>>>> is no place to construct code at runtime and have it be executable).
>>>> The mere fact that we "also build closures" is not a necessity, just
>>>> the reflection of the design decision to use the closure mechanism
>>>> instead of trampolines.
>>>>
>>>> OTHO, despite all the positive things I have said here and in another post
>>>> about trampolines, I don't favor using them, because they would make m3gdb
>>>> support a lot more difficult. m3gdb needs to be able to both read and
>>>> construct closures/trampolines, whichever. Closures are almost target-
>>>> independent, except for the native word size, which is already easily
>>>> available to m3gdb. Trampolines are going to be different for every
>>>> instruction set, and the ones constructed by compiled code, at least,
>>>> could even change with compiler version. m3gdb would need a _lot_ of
>>>> highly target-dependent code to handle them.
>>>>
>>>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>>>
>>>>>> Can any of this be removed?
>>>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>>>> generally a considered the responsibility of optimizers.
>>>>>>
>>>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>>>> Maybe I'll try without.
>>>>>>
>>>>>>
>>>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>>>
>>>>>>
>>>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>>> + m3-util.c */
>>>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>>>> +
>>>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>>>> be adding fields as necessary.
>>>>>> We also build the DECL that represents this frame in the function. */
>>>>>> @@ -209,7 +224,8 @@
>>>>>> free (name);
>>>>>> info->frame_type = type;
>>>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>>>> + info->frame_decl
>>>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>>>> /* ??? Always make it addressable for now, since it is meant to
>>>>>> be pointed to by the static chain pointer. This pessimizes
>>>>>> @@ -218,6 +234,8 @@
>>>>>> reachable, but the true pessimization is to create the non-
>>>>>> local frame structure in the first place. */
>>>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>>>> + /* m3gdb needs to know about this variable. */
>>>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>>>> return type;
>>>>>> }
>>>>>> @@ -290,6 +308,10 @@
>>>>>> return *slot;
>>>>>> }
>>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>>> + m3_util.c */
>>>>>> +static const char * static_link_var_name = "_static_link_var";
>>>>>> +
>>>>>> /* Build or return the variable that holds the static chain within
>>>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>>>> @@ -310,9 +332,14 @@
>>>>>> Note also that it's represented as a parameter. This is more
>>>>>> close to the truth, since the initial value does come from
>>>>>> the caller. */
>>>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>>>> + decl = build_decl
>>>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>>>> DECL_ARTIFICIAL (decl) = 1;
>>>>>> - DECL_IGNORED_P (decl) = 1;
>>>>>> +
>>>>>> + /* m3gdb needs to know about this variable. */
>>>>>> + DECL_IGNORED_P (decl) = 0;
>>>>>> +
>>>>>> TREE_USED (decl) = 1;
>>>>>> DECL_CONTEXT (decl) = info->context;
>>>>>> DECL_ARG_TYPE (decl) = type;
>>>>>> @@ -326,7 +353,11 @@
>>>>>> return decl;
>>>>>> }
>>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>>> + m3_util.c */
>>>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>>>> +
>>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>>>> multiple nesting levels. */
>>>>>> @@ -339,10 +370,12 @@
>>>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>>>> field = make_node (FIELD_DECL);
>>>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>>>> TREE_TYPE (field) = type;
>>>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>>>> + /* m3gdb should know about this field. */
>>>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>>>> @@ -465,7 +498,7 @@
>>>>>> return *slot;
>>>>>> }
>>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>>>> rtl middle-end as dynamic stack space is allocated. */
>>>>>> @@ -1620,6 +1653,9 @@
>>>>>> switch (TREE_CODE (t))
>>>>>> {
>>>>>> case ADDR_EXPR:
>>>>>> + if (TREE_STATIC (t))
>>>>>> + break;
>>>>>> +
>>>>>> /* Build
>>>>>> T.1 = &CHAIN->tramp;
>>>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>>>> @@ -1714,6 +1750,22 @@
>>>>>> }
>>>>>> break;
>>>>>> + case STATIC_CHAIN_EXPR:
>>>>>> + decl = TREE_OPERAND (t, 0);
>>>>>> + target_context = decl_function_context (decl);
>>>>>> + if (target_context)
>>>>>> + {
>>>>>> + if (info->context == target_context)
>>>>>> + {
>>>>>> + /* Make sure frame_decl gets created. */
>>>>>> + (void) get_frame_type (info);
>>>>>> + }
>>>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>>>> + }
>>>>>> + else
>>>>>> + *tp = null_pointer_node;
>>>>>> + break;
>>>>>> +
>>>>>> case RETURN_EXPR:
>>>>>> case GIMPLE_MODIFY_STMT:
>>>>>> case WITH_SIZE_EXPR:
>>>>>> @@ -1768,13 +1820,22 @@
>>>>>> return NULL_TREE;
>>>>>> }
>>>>>> +static bool
>>>>>> +debug_static_links (void)
>>>>>> +{ return
>>>>>> + write_symbols != NO_DEBUG
>>>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>>>> +
>>>>>> +} /* debug_static_links */
>>>>>> +
>>>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>>>> trampolines and call expressions. On the way back up, determine if
>>>>>> a nested function actually uses its static chain; if not, remember that. */
>>>>>> static void
>>>>>> convert_all_function_calls (struct nesting_info *root)
>>>>>> -{
>>>>>> +{
>>>>>> do
>>>>>> {
>>>>>> if (root->inner)
>>>>>> @@ -1784,7 +1845,10 @@
>>>>>> walk_function (convert_call_expr, root);
>>>>>> /* If the function does not use a static chain, then remember that. */
>>>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>>>> +/* REMOVE ME: */
>>>>>> + /* && !debug_static_links () */
>>>>>> + )
>>>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>>>> else
>>>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>>>> @@ -1806,6 +1870,21 @@
>>>>>> tree context = root->context;
>>>>>> struct function *sf;
>>>>>> +/* REMOVEME: */
>>>>>> + /* If this is a nested function and we are supporting debugging via
>>>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>>>> + chain, even if the programmer's code doesn't use it. */
>>>>>> + if (false && root->outer && debug_static_links () )
>>>>>> + { tree static_chain_decl, temp, stmt;
>>>>>> + /* This is a desperate attempt to get later code generation to
>>>>>> + store the static link. If it works, it'll be a miracle. */
>>>>>> + static_chain_decl = get_chain_decl (root);
>>>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>>>> + append_to_statement_list (stmt, &stmt_list);
>>>>>> + }
>>>>>> +
>>>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>>>> out at this time. */
>>>>>> if (root->frame_type)
>>>>>> @@ -1912,7 +1991,7 @@
>>>>>> proper BIND_EXPR. */
>>>>>> if (root->new_local_var_chain)
>>>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>>>> - false);
>>>>>> + true);
>>>>>> if (root->debug_var_chain)
>>>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>>>> true);
>>>>>>
>>>>>>
>>>>>>
>>>
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 27 14:54:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 12:54:39 +0000
Subject: [M3devel] a note on parse.c "GTY" use
Message-ID: <COL101-W792CCA7343DD604609EDCE6EA0@phx.gbl>


I am striving to have one parse.c be portable between gcc 4.5, gcc 4.2, and possibly gcc 4.3.
I already established 4.3/4.2 portability a year or so ago.


The main "indefinitely sticky" motivation is that Apple is only on 4.2 and they have a lot of changes.
? That I wouldn't want to merge.
We should imho, use their code for Darwin platforms, or at least Darwin/arm.
?? Mainline FSF seems to work fine for Darwin/ppc/x86 so I'm not advocating change there.



"indefinitely sticky" meaning, not really indefinite, but we aren't in control.
Presumably they'll move up to a newer version but I have no idea when.



Granted, Modula-3/iphone/pod/pad is seemingly nowhere.
A year or so ago I ran cm3 on my iPhone, got the usual "unable to find cm3.cfg", which is
exactly what you want to see when all you have is cm3 and no config files or source, and got distracted after that :)


An alternate motivation would be if we want to more easily move between 4.3 and 4.5.
This one we are more control of. If 4.5 has a few problems on a few platforms, we can
decide to debug and fix, or use 4.3 selectively.
I don't forsee problems major here though.


"Much ado about not much" -- more background than conclusion:


Gcc has some internal garbage collector. You have to annotate your code a bit for it.

In gcc 4.2/4.3 you say:

struct foo GTY()) { int field; } and such


In 4.5 you say:
struct  GTY()) foo { int field; } and such


The thing that scans your code I don't think knows much C.
I wasn't not able use #ifdef to guide it to varying versions.


Therefore, I've isolated 4.3 vs. 4.5-specific uses of GTY to their own files.
It's just a few lines.
But it is not how you would structure the code if not for this goal of working with multiple versions.


Generally otherwise I'll use #ifdef and have src/m3makefile #define whatever.
?Possibly prepending to parse.c, yucky, but oh well.
A read only source tree is ideal, granted, but I do what I can..


GTY is presumably "garbabe collected type" or such.



?- Jay
 		 	   		  

From jay.krell at cornell.edu  Thu May 27 15:07:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 13:07:10 +0000
Subject: [M3devel] a note on parse.c "GTY" use
In-Reply-To: <COL101-W792CCA7343DD604609EDCE6EA0@phx.gbl>
References: <COL101-W792CCA7343DD604609EDCE6EA0@phx.gbl>
Message-ID: <COL101-W3071349CB8D692DC65B62FE6EA0@phx.gbl>


Hm. Alternatively we could possibly use the data C types...

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 27 May 2010 12:54:39 +0000
> Subject: [M3devel] a note on parse.c "GTY" use
>
>
> I am striving to have one parse.c be portable between gcc 4.5, gcc 4.2, and possibly gcc 4.3.
> I already established 4.3/4.2 portability a year or so ago.
>
>
> The main "indefinitely sticky" motivation is that Apple is only on 4.2 and they have a lot of changes.
>   That I wouldn't want to merge.
> We should imho, use their code for Darwin platforms, or at least Darwin/arm.
>    Mainline FSF seems to work fine for Darwin/ppc/x86 so I'm not advocating change there.
>
>
>
> "indefinitely sticky" meaning, not really indefinite, but we aren't in control.
> Presumably they'll move up to a newer version but I have no idea when.
>
>
>
> Granted, Modula-3/iphone/pod/pad is seemingly nowhere.
> A year or so ago I ran cm3 on my iPhone, got the usual "unable to find cm3.cfg", which is
> exactly what you want to see when all you have is cm3 and no config files or source, and got distracted after that :)
>
>
> An alternate motivation would be if we want to more easily move between 4.3 and 4.5.
> This one we are more control of. If 4.5 has a few problems on a few platforms, we can
> decide to debug and fix, or use 4.3 selectively.
> I don't forsee problems major here though.
>
>
> "Much ado about not much" -- more background than conclusion:
>
>
> Gcc has some internal garbage collector. You have to annotate your code a bit for it.
>
> In gcc 4.2/4.3 you say:
>
> struct foo GTY()) { int field; } and such
>
>
> In 4.5 you say:
> struct GTY()) foo { int field; } and such
>
>
> The thing that scans your code I don't think knows much C.
> I wasn't not able use #ifdef to guide it to varying versions.
>
>
> Therefore, I've isolated 4.3 vs. 4.5-specific uses of GTY to their own files.
> It's just a few lines.
> But it is not how you would structure the code if not for this goal of working with multiple versions.
>
>
> Generally otherwise I'll use #ifdef and have src/m3makefile #define whatever.
>  Possibly prepending to parse.c, yucky, but oh well.
> A read only source tree is ideal, granted, but I do what I can..
>
>
> GTY is presumably "garbabe collected type" or such.
>
>
>
>  - Jay
>
 		 	   		  

From rodney_bates at lcwb.coop  Fri May 28 02:50:51 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 27 May 2010 19:50:51 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
	<col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
Message-ID: <4BFF136B.7020609@lcwb.coop>



Jay K wrote:
> I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
>  
>  
> I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
>   Because it has a similar but inferior mechanism.
>  
>  
> One wonders about Ada though -- does it supported nested functions?
>   I noticed it bears a striking resembles to Pascal/Modula-3. :)

Ada does have nested procedures, but it does not have variables or parameters
of procedure type at all, and it is these that need a closure/trampoline
mechanism, to hold a pointer to the "environment"  of the runtime procedure
value.

Actually, Ada has a form of procedure parameters, but they are
"generic" parameters, which means "instantiation" (i.e., supplying
the actual procedure parameter) is done statically.  This pretty
much always means the program unit with the procedure parameter
is copied at compile time and modified accordingly.

>  
> And uses the same not great trampoline mechanism?
>  
>  
> If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
> Those are two very big ifs.
>  
>  
> Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?

Yes,  The environment (address of the activation record) is in the closure.  If we used trampolines,
it would be in the trampoline instead.  m3gdb has to read these when an m3gdb expression contains
a call on a parameter of procedure type, to correctly execute the call.  It has to construct a
closure (or, again, it would be a trampoline, if we used them instead) to execute a call that
contains a nested procedure as an actual parameter.

> Ah.
> We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
>  
>                              -- pointer to function --
>                              -- parameter/static chain whatever --

                                   ^ For a single function, there can be many values of this.  Since this scheme
puts it right before the code of the nested procedure, there could only be one value of it.  Every different
parameter (to some other procedure, usually) can have a different environment.  So this won't work.

>  trampoline points here =>   -- start of code --
>                              -- target dependent position independent not very optimized
>                              -- *constant* hand crafted code that fetchs the data from just before itself
>  
>  
> Would that address the m3gdb problem?
>  Putting the data at fixed negative offsets from the trampoline code?
>  Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
>   to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
>  
>  
> Granted, crafting that code would be.. fun. :)
> Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
>  
>  
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:33:52 -0400
>> To: rodney_bates at lcwb.coop
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>>
>> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>>
>>>
>>> Tony Hosking wrote:
>>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>> I don't follow the last part of this argument. If we follow the first
>>> principle, we would just use trampolines, since they are the same
>>> mechanism the C compiler uses. And the only place they are not possible
>>> are places where they won't work for C either (e.g., a target where there
>>> is no place to construct code at runtime and have it be executable).
>>> The mere fact that we "also build closures" is not a necessity, just
>>> the reflection of the design decision to use the closure mechanism
>>> instead of trampolines.
>>>
>>> OTHO, despite all the positive things I have said here and in another post
>>> about trampolines, I don't favor using them, because they would make m3gdb
>>> support a lot more difficult. m3gdb needs to be able to both read and
>>> construct closures/trampolines, whichever. Closures are almost target-
>>> independent, except for the native word size, which is already easily
>>> available to m3gdb. Trampolines are going to be different for every
>>> instruction set, and the ones constructed by compiled code, at least,
>>> could even change with compiler version. m3gdb would need a _lot_ of
>>> highly target-dependent code to handle them.
>>>
>>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>> Can any of this be removed?
>>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>>> generally a considered the responsibility of optimizers.
>>>>>
>>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>>> Maybe I'll try without.
>>>>>
>>>>>
>>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>>
>>>>>
>>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3-util.c */
>>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>>> +
>>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>>> be adding fields as necessary.
>>>>> We also build the DECL that represents this frame in the function. */
>>>>> @@ -209,7 +224,8 @@
>>>>> free (name);
>>>>> info->frame_type = type;
>>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>>> + info->frame_decl
>>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>>> /* ??? Always make it addressable for now, since it is meant to
>>>>> be pointed to by the static chain pointer. This pessimizes
>>>>> @@ -218,6 +234,8 @@
>>>>> reachable, but the true pessimization is to create the non-
>>>>> local frame structure in the first place. */
>>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>>> return type;
>>>>> }
>>>>> @@ -290,6 +308,10 @@
>>>>> return *slot;
>>>>> }
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_var_name = "_static_link_var";
>>>>> +
>>>>> /* Build or return the variable that holds the static chain within
>>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>>> @@ -310,9 +332,14 @@
>>>>> Note also that it's represented as a parameter. This is more
>>>>> close to the truth, since the initial value does come from
>>>>> the caller. */
>>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>>> + decl = build_decl
>>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>>> DECL_ARTIFICIAL (decl) = 1;
>>>>> - DECL_IGNORED_P (decl) = 1;
>>>>> +
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (decl) = 0;
>>>>> +
>>>>> TREE_USED (decl) = 1;
>>>>> DECL_CONTEXT (decl) = info->context;
>>>>> DECL_ARG_TYPE (decl) = type;
>>>>> @@ -326,7 +353,11 @@
>>>>> return decl;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>>> +
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>>> multiple nesting levels. */
>>>>> @@ -339,10 +370,12 @@
>>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>>> field = make_node (FIELD_DECL);
>>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>>> TREE_TYPE (field) = type;
>>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>>> + /* m3gdb should know about this field. */
>>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>>> @@ -465,7 +498,7 @@
>>>>> return *slot;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>>> rtl middle-end as dynamic stack space is allocated. */
>>>>> @@ -1620,6 +1653,9 @@
>>>>> switch (TREE_CODE (t))
>>>>> {
>>>>> case ADDR_EXPR:
>>>>> + if (TREE_STATIC (t))
>>>>> + break;
>>>>> +
>>>>> /* Build
>>>>> T.1 = &CHAIN->tramp;
>>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>>> @@ -1714,6 +1750,22 @@
>>>>> }
>>>>> break;
>>>>> + case STATIC_CHAIN_EXPR:
>>>>> + decl = TREE_OPERAND (t, 0);
>>>>> + target_context = decl_function_context (decl);
>>>>> + if (target_context)
>>>>> + {
>>>>> + if (info->context == target_context)
>>>>> + {
>>>>> + /* Make sure frame_decl gets created. */
>>>>> + (void) get_frame_type (info);
>>>>> + }
>>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>>> + }
>>>>> + else
>>>>> + *tp = null_pointer_node;
>>>>> + break;
>>>>> +
>>>>> case RETURN_EXPR:
>>>>> case GIMPLE_MODIFY_STMT:
>>>>> case WITH_SIZE_EXPR:
>>>>> @@ -1768,13 +1820,22 @@
>>>>> return NULL_TREE;
>>>>> }
>>>>> +static bool
>>>>> +debug_static_links (void)
>>>>> +{ return
>>>>> + write_symbols != NO_DEBUG
>>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>>> +
>>>>> +} /* debug_static_links */
>>>>> +
>>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>>> trampolines and call expressions. On the way back up, determine if
>>>>> a nested function actually uses its static chain; if not, remember that. */
>>>>> static void
>>>>> convert_all_function_calls (struct nesting_info *root)
>>>>> -{
>>>>> +{
>>>>> do
>>>>> {
>>>>> if (root->inner)
>>>>> @@ -1784,7 +1845,10 @@
>>>>> walk_function (convert_call_expr, root);
>>>>> /* If the function does not use a static chain, then remember that. */
>>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>>> +/* REMOVE ME: */
>>>>> + /* && !debug_static_links () */
>>>>> + )
>>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>>> else
>>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>>> @@ -1806,6 +1870,21 @@
>>>>> tree context = root->context;
>>>>> struct function *sf;
>>>>> +/* REMOVEME: */
>>>>> + /* If this is a nested function and we are supporting debugging via
>>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>>> + chain, even if the programmer's code doesn't use it. */
>>>>> + if (false && root->outer && debug_static_links () )
>>>>> + { tree static_chain_decl, temp, stmt;
>>>>> + /* This is a desperate attempt to get later code generation to
>>>>> + store the static link. If it works, it'll be a miracle. */
>>>>> + static_chain_decl = get_chain_decl (root);
>>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>>> + append_to_statement_list (stmt, &stmt_list);
>>>>> + }
>>>>> +
>>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>>> out at this time. */
>>>>> if (root->frame_type)
>>>>> @@ -1912,7 +1991,7 @@
>>>>> proper BIND_EXPR. */
>>>>> if (root->new_local_var_chain)
>>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>>> - false);
>>>>> + true);
>>>>> if (root->debug_var_chain)
>>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>>> true);
>>>>>
>>>>>
>>>>>
>> 		 	   		  


From rodney_bates at lcwb.coop  Fri May 28 03:01:02 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 27 May 2010 20:01:02 -0500
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>, ,
	<4BFDA293.9080503@lcwb.coop>,
	<COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>,
	<665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
	<COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>
Message-ID: <4BFF15CE.7060908@lcwb.coop>



Jay K wrote:
> Shouldn't gcc be able to optimize about as well any such transform?
>   Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
>  
> Anyway, ok.
>  
> There's stuff I have to figure out and understand here either way.
>  
> Like, does the the static chain "flow" through non-nested calls?

The static chain flows through a series of activation records of calls
on progressively more shallowly nested procedures, until the last link
in the chain leads to an activation of a non-nested procedure.  Here the
static chain ends.

Conceptually, it would be convenient and consistent to think of this non-nested
procedure as having one more static link pointing to an area where all global
variables are stored, but in reality, almost no runtime addressing model does this.
Since globals have whole-program lifetime and always exactly one instance,
it is better to address them in some other way.

Note the static chain is needed for nested procedures even if there
are no procedure variables or parameters.  (e.g. Ada).

>  
>  - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:27:56 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>>
>>
>>
>> Argh!!!!!
>> No! We don't want to do work in the front-end to get rid of nesting.
>> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>>
>>
>>
>>
>> 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 26 May 2010, at 18:53, Jay K wrote:
>>
>>
>> Rodney, When you get back to it, can you just dig it out of history?
>>
>>
>> I still think we should try to avoid gcc's nested function functionality.
>>
>>
>> Where you use the static chain, not using the nested function functionality should
>> "automatically" be debuggable -- "automatic" as in, once the work is done
>> in the frontend to transform out nesting.
>>
>>
>> "debuggable" as in, you could follow the links yourself in the debugger.
>> The debugger need not search lexically nested functions that have function
>> calls dividing them.
>>
>>
>> ?
>>
>>
>> There's stuff I still need to understand better -- particularly the affect of nested functions
>> on non-nested functions. Is there *always* an extra parameter to *all* functions?
>> It appears so.
>> And I haven't figured out how to merge with 4.5 what I think achieves that.
>>
>>
>> Maybe a good test of test cases here?
>>
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>> Date: Wed, 26 May 2010 17:37:07 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>>
>> I left it in because it is a work in progress. I *really* want to get it to
>> work, and I don't what to have to reinvent what is already there when I get
>> to it. I use nested procedures extensively in certain situations, and good
>> debugger support of them is important to me. It all works fine on older code
>> generators than the gcc that added tree-nested.c.
>>
>> Jay K wrote:
>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>> Does it work?
>> Does it accomplish anything?
>> Can I remove it and its calls?
>>
>> /* Special-purpose function to write stabs for the static_chain_decl.
>> So far, this is not working. m3gdb needs the place in the activation
>> record where the SL is stored. Right now, the SL is not necessarily
>> stored at all, but may just be kept in a register. DECL_RTL and
>> DECL_INCOMING_RTL may both have register expressions. But stabs
>> entries for register variables, of kind N_RSYM, are currently ignored
>> by gdb in dbxread.c, and making it read them could create problems
>> elsewhere, because there can be other variables for which both an
>> N_RSYM and an N_LSYM stabs entry are created.
>> */
>> static int
>> dbxout_static_chain_decl (tree decl)
>>
>> It was added 19 months ago by:
>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>
>> as well, do we need the #if 0 code added then?
>>
>> - Jay
>>
>> 		 	   		  


From rodney_bates at lcwb.coop  Fri May 28 03:13:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 27 May 2010 20:13:46 -0500
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>,
	<4BFDACC6.6020600@lcwb.coop>
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>
Message-ID: <4BFF18CA.5070107@lcwb.coop>



Jay K wrote:
> Rodney, It's not a data size optimization. It is a code size optimization.
> Adding the padding is ok.
>  

I guess I am really confused here.  I thought you have been advocating making the
closure marker smaller than the native word size.  I don't see how this would
make closures that are not aligned be aligned.  Even if it did help with
the test of the closure marker, the fetching of the environment pointer and
code pointer would still have the same problem, and they can't be made shorter,
because they need all the bits for their values.

Any way, if you don't like the code that non-aligned closures require, why not
just choose to align them?  It seem so much easier than trying to micro-optimize
the code that solves an ugly problem.

>  
>  
> See Aligned_procedures use in.
> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
>  
> PROCEDURE If_closure (proc: Val;  true, false: Label;  freq: Frequency) =
>   VAR skip := Next_label ();  nope := skip;
>   BEGIN
>     IF (false # No_label) THEN  nope := false; END;
>     IF NOT Target.Aligned_procedures THEN
>       Push (proc);
>       Force ();
>       cg.loophole (Type.Addr, Target.Integer.cg_type);
>       Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
>       cg.and (Target.Integer.cg_type);
>       cg.if_true (Target.Integer.cg_type, nope, Always - freq);
>       SPop (1, "If_closure-unaligned");
>     END;
>     Push (proc);
>     Boost_alignment (Target.Address.align);
>     Force ();
>     cg.load_nil ();
>     cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
>     Push (proc);
>     Boost_alignment (Target.Integer.align);
>     Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
>     Push_int (M3RT.CL_marker_value);
>     IF (true # No_label)
>       THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
>       ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
>     END;
>     Set_label (skip);
>     SPop (2, "If_closure");
>   END If_closure;
>  
>  
> Aligned_procedures would become effectively always true.
> Code would be reduced.
>  
>  
> I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
>  
>  
>  - Jay
> 
> 
> 
> ----------------------------------------
>> Date: Wed, 26 May 2010 18:20:38 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] closure marker
>>
>> After the marker, a closure also has two pointers, one to executable code,
>> and one to an environment of nonlocal variables. These will always have
>> to be aligned to whatever pointers require on the target. So making the
>> marker smaller than a native pointer would then require padding the
>> closure to get the pointers aligned. This uses as much space as just
>> keeping the marker word-sized.
>>
>> And no, I don't think it makes any sense to (on a 64-bit target) start
>> a closure on an odd multiple of 4 bytes, just so you can make the marker
>> smaller while keeping the following pointers word-aligned.
>>
>> Jay K wrote:
>>> A little bit of research done (just searching the web):
>>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>>
>>>
>>> all appear to use a 32bit instruction
>>> presumably aligned but I couldn't confirm for all of them.
>>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>>
>>>
>>> Looks like SH has 16bit instructions.
>>>
>>>
>>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>>> With IA64 the expected exception with size=64bits, count=2.
>>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>>> We can revisit at that time.
>>> And really size=64, count=1 might suffice.
>>>
>>> I'm a little torn.
>>> A 64bit marker is more certain.
>>> Code has been this way forever.
>>> etc.
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>>> Subject: closure marker
>>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>>
>>>>
>>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>>> 64bit systems that care about alignment pay quite a penality imho.
>>>>
>>>>
>>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>>
>>>>
>>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>>
>>>>
>>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>>
>>>>
>>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>>
>>>>
>>>> More general might be
>>>> Target.ClosureElementSize (bits)
>>>> Target.ClosureElementCount
>>>>
>>>>
>>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>>
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>> 		 	   		  


From jay.krell at cornell.edu  Fri May 28 05:42:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 28 May 2010 03:42:09 +0000
Subject: [M3devel] closure marker
In-Reply-To: <4BFF18CA.5070107@lcwb.coop>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>, ,
	<4BFDACC6.6020600@lcwb.coop>,
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>,
	<4BFF18CA.5070107@lcwb.coop>
Message-ID: <COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>


What I'm describing is keep the closure the same -- integer -1, integer function pointer, integer chain.
But only read 4 bytes when checking for the -1.
Closures are always integer-aligned, but function pointers are not generally.
The code to check if it is a closure would just read 4 bytes and compare to -1, not check the alignment and then read integer-bytes.


Besides the micro-optimization, it *almost* eliminates target-specific code.
? Every time I ported to a system that cares about alignment I wasted time on this.
? Partly that was just because I didn't know about it. Now I know. Future ports easier.

The problem I think is that IA64 works neither with this scheme nor the existing scheme. Not sure.
? Seems more clear IA64 should have 128bit marker. But maybe 64bits are ok.
? If the bundle format is in the first 64 bits, not sure, and given that all bits 1 is an invalid bundle, then...
And possibly SH where code isn't necessarily 4-aligned. Not sure.

?- Jay

----------------------------------------
> Date: Thu, 27 May 2010 20:13:46 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
>
>
> Jay K wrote:
>> Rodney, It's not a data size optimization. It is a code size optimization.
>> Adding the padding is ok.
>>
>
> I guess I am really confused here. I thought you have been advocating making the
> closure marker smaller than the native word size. I don't see how this would
> make closures that are not aligned be aligned. Even if it did help with
> the test of the closure marker, the fetching of the environment pointer and
> code pointer would still have the same problem, and they can't be made shorter,
> because they need all the bits for their values.
>
> Any way, if you don't like the code that non-aligned closures require, why not
> just choose to align them? It seem so much easier than trying to micro-optimize
> the code that solves an ugly problem.
>
>>
>>
>> See Aligned_procedures use in.
>> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
>>
>> PROCEDURE If_closure (proc: Val; true, false: Label; freq: Frequency) =
>> VAR skip := Next_label (); nope := skip;
>> BEGIN
>> IF (false # No_label) THEN nope := false; END;
>> IF NOT Target.Aligned_procedures THEN
>> Push (proc);
>> Force ();
>> cg.loophole (Type.Addr, Target.Integer.cg_type);
>> Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
>> cg.and (Target.Integer.cg_type);
>> cg.if_true (Target.Integer.cg_type, nope, Always - freq);
>> SPop (1, "If_closure-unaligned");
>> END;
>> Push (proc);
>> Boost_alignment (Target.Address.align);
>> Force ();
>> cg.load_nil ();
>> cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
>> Push (proc);
>> Boost_alignment (Target.Integer.align);
>> Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
>> Push_int (M3RT.CL_marker_value);
>> IF (true # No_label)
>> THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
>> ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
>> END;
>> Set_label (skip);
>> SPop (2, "If_closure");
>> END If_closure;
>>
>>
>> Aligned_procedures would become effectively always true.
>> Code would be reduced.
>>
>>
>> I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
>>
>>
>> - Jay
>>
>>
>>
>> ----------------------------------------
>>> Date: Wed, 26 May 2010 18:20:38 -0500
>>> From: rodney_bates at lcwb.coop
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] closure marker
>>>
>>> After the marker, a closure also has two pointers, one to executable code,
>>> and one to an environment of nonlocal variables. These will always have
>>> to be aligned to whatever pointers require on the target. So making the
>>> marker smaller than a native pointer would then require padding the
>>> closure to get the pointers aligned. This uses as much space as just
>>> keeping the marker word-sized.
>>>
>>> And no, I don't think it makes any sense to (on a 64-bit target) start
>>> a closure on an odd multiple of 4 bytes, just so you can make the marker
>>> smaller while keeping the following pointers word-aligned.
>>>
>>> Jay K wrote:
>>>> A little bit of research done (just searching the web):
>>>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>>>
>>>>
>>>> all appear to use a 32bit instruction
>>>> presumably aligned but I couldn't confirm for all of them.
>>>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>>>
>>>>
>>>> Looks like SH has 16bit instructions.
>>>>
>>>>
>>>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>>>> With IA64 the expected exception with size=64bits, count=2.
>>>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>>>> We can revisit at that time.
>>>> And really size=64, count=1 might suffice.
>>>>
>>>> I'm a little torn.
>>>> A 64bit marker is more certain.
>>>> Code has been this way forever.
>>>> etc.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>>>> Subject: closure marker
>>>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>>>
>>>>>
>>>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>>>> 64bit systems that care about alignment pay quite a penality imho.
>>>>>
>>>>>
>>>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>>>
>>>>>
>>>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>>>
>>>>>
>>>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>>>
>>>>>
>>>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>>>
>>>>>
>>>>> More general might be
>>>>> Target.ClosureElementSize (bits)
>>>>> Target.ClosureElementCount
>>>>>
>>>>>
>>>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>
 		 	   		  

From hendrik at topoi.pooq.com  Sat May 29 00:04:01 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 28 May 2010 18:04:01 -0400
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <4BFF15CE.7060908@lcwb.coop>
References: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
	<COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>
	<4BFF15CE.7060908@lcwb.coop>
Message-ID: <20100528220400.GB4904@topoi.pooq.com>

On Thu, May 27, 2010 at 08:01:02PM -0500, Rodney M. Bates wrote:
>
>
> Jay K wrote:
>> Shouldn't gcc be able to optimize about as well any such transform?
>>   Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
>>  Anyway, ok.
>>  There's stuff I have to figure out and understand here either way.
>>  Like, does the the static chain "flow" through non-nested calls?
>
> The static chain flows through a series of activation records of calls
> on progressively more shallowly nested procedures, until the last link
> in the chain leads to an activation of a non-nested procedure.  Here the
> static chain ends.
>
> Conceptually, it would be convenient and consistent to think of this non-nested
> procedure as having one more static link pointing to an area where all global
> variables are stored, but in reality, almost no runtime addressing model does this.
> Since globals have whole-program lifetime and always exactly one instance,
> it is better to address them in some other way.
>
> Note the static chain is needed for nested procedures even if there
> are no procedure variables or parameters.  (e.g. Ada).

In Algol 68, when it's implemented using static links, the static chain 
doesn't thread *all* the chain of surrounding procedures -- it skips the 
ones that don't define any names used in the inner ones.

This bit of denesting might improve efficiency even in Modula 3, since 
some static chains might end up being shorter.  Whether it's worth the 
effort is another question, of course.

-- hendrik

>>> Argh!!!!!
>>> No! We don't want to do work in the front-end to get rid of nesting.
>>> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>>>
>>> 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


From hendrik at topoi.pooq.com  Sat May 29 00:07:20 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 28 May 2010 18:07:20 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <4BFDA90A.3050105@lcwb.coop>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>
	<4BFDA90A.3050105@lcwb.coop>
Message-ID: <20100528220720.GC4904@topoi.pooq.com>

On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>
>
> Jay K wrote:
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>
>>>
>>>
>>> We should endeavour to use the same functionality that the C compiler 
>>> uses for its own nested functions, 
>
> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>
>>
>> Right..for those that don't know..
>>
>>
>> There's no "good" efficient way to implement nested functions.
>> Our implementation is pretty "bad".
>> gcc's implementation is pretty "bad".
>
> I think this is far too critical.  The inefficiencies you see are
> minor.  Certainly no worse than the implementation of dispatching
> methods of objects, something the world is gaga about.

Sufficiently gaga that hardware manufacturers are trying to make it 
really fast.  Things like fetch- and branch- prediction.

We may as well use them if there isn't something better around.

-- hendrik


From jay.krell at cornell.edu  Sat May 29 05:10:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 29 May 2010 03:10:46 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <20100528220720.GC4904@topoi.pooq.com>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>,
	<20100528220720.GC4904@topoi.pooq.com>
Message-ID: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>


Ok ok let me explain my "real" questions.
 
 
 
 - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
 
 
 
and/or
 
 
 
 
 - Can someone show me how the above translates to C?
   Or Modula-3 with no nested functions.
   Using Modula-3 closures.
   It's not about the syntax, it's about a lower level model.
   Bonus points if you can show me the translation to C-like code with gcc trampolines also.
     That's mainly currently just for curiosity.
 
 
 
and/or
 
 
 
 - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
 
 
 
Like, I need to understand what to do for gcc 4.5.0.
 
 
Some of the tree-nested changes refer to a particular test case.
I'll look there to start.
 
 
 
In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
With a comment that maybe we could do it better.
The context in 4.5 is vastly different now.
The 4.3 changes "completely unmergable".
  I even looked around for somewhere else to put them.
 
 
 
Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
 Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
 
 
 
I'll see if I can get some clues here:
  http://gcc.gnu.org/onlinedocs/gccint/
 
 
:)
 
 
 - Jay




----------------------------------------
> Date: Fri, 28 May 2010 18:07:20 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>
>>
>> Jay K wrote:
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>
>>>>
>>>>
>>>> We should endeavour to use the same functionality that the C compiler
>>>> uses for its own nested functions,
>>
>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>
>>>
>>> Right..for those that don't know..
>>>
>>>
>>> There's no "good" efficient way to implement nested functions.
>>> Our implementation is pretty "bad".
>>> gcc's implementation is pretty "bad".
>>
>> I think this is far too critical. The inefficiencies you see are
>> minor. Certainly no worse than the implementation of dispatching
>> methods of objects, something the world is gaga about.
>
> Sufficiently gaga that hardware manufacturers are trying to make it
> really fast. Things like fetch- and branch- prediction.
>
> We may as well use them if there isn't something better around.
>
> -- hendrik 		 	   		  

From hendrik at topoi.pooq.com  Sat May 29 10:43:35 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 29 May 2010 04:43:35 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
References: <20100528220720.GC4904@topoi.pooq.com>
	<COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
Message-ID: <20100529084334.GA10658@topoi.pooq.com>

On Sat, May 29, 2010 at 03:10:46AM +0000, Jay K wrote:
> 
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  

Here's the classic test, in Algol 60:

begin
  real procedure A (k, x1, x2, x3, x4, x5);
  value k; integer k;
  begin
    real procedure B;
    begin k:= k - 1;
          B:= A := A (k, B, x1, x2, x3, x4);
    end;
    if k <= 0 then A:= x4 + x5 else B;
  end;
  outreal (A (10, 1, -1, -1, 1, 0));
end;

reference:

http://en.wikipedia.org/wiki/Man_or_boy_test

See also:

http://www.rosettacode.org/wiki/Man_or_boy_test

This page has a version which simulates closures in C.

-- hendrik


From rodney_bates at lcwb.coop  Sat May 29 22:03:58 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 29 May 2010 15:03:58 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>,
	<20100528220720.GC4904@topoi.pooq.com>
	<COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
Message-ID: <4C01732E.1070609@lcwb.coop>



Jay K wrote:
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  
>  
>  
> and/or
>  
>  
>  
>  
>  - Can someone show me how the above translates to C?
>    Or Modula-3 with no nested functions.
>    Using Modula-3 closures.
>    It's not about the syntax, it's about a lower level model.
>    Bonus points if you can show me the translation to C-like code with gcc trampolines also.
>      That's mainly currently just for curiosity.
>  
>  

I'm about to travel for a week, but maybe I'll give this a shot when I get back.
The problem is, it needs some diagrams, and I'm not fluent in any diagram
editor.  Maybe I can find/recommend a section of a good compiler book on this.

>  
> and/or
>  
>  
>  
>  - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
>  

I believe all that changes to tree-nested.c are mine, and they are only for debugging
support.  If the new tree-nested.c is very different, perhaps I should look at it.

>  
>  
> Like, I need to understand what to do for gcc 4.5.0.
>  
>  
> Some of the tree-nested changes refer to a particular test case.
> I'll look there to start.
>  
>  
>  
> In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
> With a comment that maybe we could do it better.
> The context in 4.5 is vastly different now.
> The 4.3 changes "completely unmergable".
>   I even looked around for somewhere else to put them.
>  
>  
>  
> Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
>  Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
>  
>  
>  
> I'll see if I can get some clues here:
>   http://gcc.gnu.org/onlinedocs/gccint/
>  
>  
> :)
>  
>  
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> Date: Fri, 28 May 2010 18:07:20 -0400
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>>
>>> Jay K wrote:
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>>
>>>>>
>>>>>
>>>>> We should endeavour to use the same functionality that the C compiler
>>>>> uses for its own nested functions,
>>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> Right..for those that don't know..
>>>>
>>>>
>>>> There's no "good" efficient way to implement nested functions.
>>>> Our implementation is pretty "bad".
>>>> gcc's implementation is pretty "bad".
>>> I think this is far too critical. The inefficiencies you see are
>>> minor. Certainly no worse than the implementation of dispatching
>>> methods of objects, something the world is gaga about.
>> Sufficiently gaga that hardware manufacturers are trying to make it
>> really fast. Things like fetch- and branch- prediction.
>>
>> We may as well use them if there isn't something better around.
>>
>> -- hendrik 		 	   		  


From rodney_bates at lcwb.coop  Sat May 29 22:26:11 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 29 May 2010 15:26:11 -0500
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>, ,
	<4BFDACC6.6020600@lcwb.coop>,
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>,
	<4BFF18CA.5070107@lcwb.coop>
	<COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>
Message-ID: <4C017863.2070209@lcwb.coop>

I might be starting to get the picture.  Here's what I think I understand so far:

On the target in question, native word is 64 bits.  Closures are three words, as
usual, all 64-bits and aligned to 64 bits.

The problem comes from the fact that, on this target, the first instruction of
the code of a procedure is not necessarily aligned to 64 bit.

So, when you have a parameter of procedure type, you can't immediately test
whether it points to a closure marker, because if not, it might be a code address
that is not a multiple of 8 bytes, and the attempt to test for the entire 64-bit
marker would suffer an alignment fault.

So, the generated code first tests whether it is a multiple of 8.  If not, that
means it points directly to code.  If so, it still could point to either code or
a closure, but now testing for the marker will not alignment-fault.  And it is
the first test you want to eliminate, right?

And your proposal is to code the marker test to only check a 32-bit half word
for all ones.  This will work for code addresses that are not multiples of 8,
but will still require them to be multiples of 4.

If Target.Aligned_procedures=FALSE really means they are not necessarily 8-byte aligned,
but are necessarily 4-byte aligned, which you need, then I think it is misnamed.
To me, and I think about anybody, I would expect Aligned_procedures=FALSE to mean
they are not aligned at all.  What does it actually mean, for various targets with
various native word sizes?

One approach would be to just make all first instructions of procedures be on
8-byte boundaries.   Aligned_procedures would be TRUE, and the extra code would
not be generated.  Actually, it is hard for me to imagine a modern object module
format and linker the did not ensure this, as I understand that usually, linkers
can selectively remove unreferenced procedures.  This would require the code of
every procedure to be in a separate "section" or whatever, which would then mean
it would be maximally aligned.

Another would be to ascertain that, in the targets where NOT Aligned_procedures,
a byte containing 16_FF can not be the first byte of any opcode.  If so, you
could just have the marker check test only one byte.  (But still build markers
the full length, just for consistency.)

Lacking any of the above, I'd just leave the extra code in there.

Jay K wrote:
> What I'm describing is keep the closure the same -- integer -1, integer function pointer, integer chain.
> But only read 4 bytes when checking for the -1.
> Closures are always integer-aligned, but function pointers are not generally.
> The code to check if it is a closure would just read 4 bytes and compare to -1, not check the alignment and then read integer-bytes.
> 
> 
> Besides the micro-optimization, it *almost* eliminates target-specific code.
>   Every time I ported to a system that cares about alignment I wasted time on this.
>   Partly that was just because I didn't know about it. Now I know. Future ports easier.
> 
> The problem I think is that IA64 works neither with this scheme nor the existing scheme. Not sure.
>   Seems more clear IA64 should have 128bit marker. But maybe 64bits are ok.
>   If the bundle format is in the first 64 bits, not sure, and given that all bits 1 is an invalid bundle, then...
> And possibly SH where code isn't necessarily 4-aligned. Not sure.
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Thu, 27 May 2010 20:13:46 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] closure marker
>>
>>
>>
>> Jay K wrote:
>>> Rodney, It's not a data size optimization. It is a code size optimization.
>>> Adding the padding is ok.
>>>
>> I guess I am really confused here. I thought you have been advocating making the
>> closure marker smaller than the native word size. I don't see how this would
>> make closures that are not aligned be aligned. Even if it did help with
>> the test of the closure marker, the fetching of the environment pointer and
>> code pointer would still have the same problem, and they can't be made shorter,
>> because they need all the bits for their values.
>>
>> Any way, if you don't like the code that non-aligned closures require, why not
>> just choose to align them? It seem so much easier than trying to micro-optimize
>> the code that solves an ugly problem.
>>
>>>
>>> See Aligned_procedures use in.
>>> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
>>>
>>> PROCEDURE If_closure (proc: Val; true, false: Label; freq: Frequency) =
>>> VAR skip := Next_label (); nope := skip;
>>> BEGIN
>>> IF (false # No_label) THEN nope := false; END;
>>> IF NOT Target.Aligned_procedures THEN
>>> Push (proc);
>>> Force ();
>>> cg.loophole (Type.Addr, Target.Integer.cg_type);
>>> Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
>>> cg.and (Target.Integer.cg_type);
>>> cg.if_true (Target.Integer.cg_type, nope, Always - freq);
>>> SPop (1, "If_closure-unaligned");
>>> END;
>>> Push (proc);
>>> Boost_alignment (Target.Address.align);
>>> Force ();
>>> cg.load_nil ();
>>> cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
>>> Push (proc);
>>> Boost_alignment (Target.Integer.align);
>>> Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
>>> Push_int (M3RT.CL_marker_value);
>>> IF (true # No_label)
>>> THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
>>> ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
>>> END;
>>> Set_label (skip);
>>> SPop (2, "If_closure");
>>> END If_closure;
>>>
>>>
>>> Aligned_procedures would become effectively always true.
>>> Code would be reduced.
>>>
>>>
>>> I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Date: Wed, 26 May 2010 18:20:38 -0500
>>>> From: rodney_bates at lcwb.coop
>>>> To: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] closure marker
>>>>
>>>> After the marker, a closure also has two pointers, one to executable code,
>>>> and one to an environment of nonlocal variables. These will always have
>>>> to be aligned to whatever pointers require on the target. So making the
>>>> marker smaller than a native pointer would then require padding the
>>>> closure to get the pointers aligned. This uses as much space as just
>>>> keeping the marker word-sized.
>>>>
>>>> And no, I don't think it makes any sense to (on a 64-bit target) start
>>>> a closure on an odd multiple of 4 bytes, just so you can make the marker
>>>> smaller while keeping the following pointers word-aligned.
>>>>
>>>> Jay K wrote:
>>>>> A little bit of research done (just searching the web):
>>>>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>>>>
>>>>>
>>>>> all appear to use a 32bit instruction
>>>>> presumably aligned but I couldn't confirm for all of them.
>>>>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>>>>
>>>>>
>>>>> Looks like SH has 16bit instructions.
>>>>>
>>>>>
>>>>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>>>>> With IA64 the expected exception with size=64bits, count=2.
>>>>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>>>>> We can revisit at that time.
>>>>> And really size=64, count=1 might suffice.
>>>>>
>>>>> I'm a little torn.
>>>>> A 64bit marker is more certain.
>>>>> Code has been this way forever.
>>>>> etc.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>>>>> Subject: closure marker
>>>>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>>>>
>>>>>>
>>>>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>>>>> 64bit systems that care about alignment pay quite a penality imho.
>>>>>>
>>>>>>
>>>>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>>>>
>>>>>>
>>>>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>>>>
>>>>>>
>>>>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>>>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>>>>
>>>>>>
>>>>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>>>>
>>>>>>
>>>>>> More general might be
>>>>>> Target.ClosureElementSize (bits)
>>>>>> Target.ClosureElementCount
>>>>>>
>>>>>>
>>>>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>>>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>>>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>  		 	   		  


From rodney_bates at lcwb.coop  Sat May 29 23:17:25 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 29 May 2010 16:17:25 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>,
	<20100528220720.GC4904@topoi.pooq.com>
	<COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
Message-ID: <4C018465.7000204@lcwb.coop>

More concerning tree-nested.c:

I am now remembering that there was some inconsistent terminology in
tree-nested.c, calling the same thing by different names, etc, in
comments, and, I think, in some identifiers too.  One thing I did
was clean this up, after having to unravel it for the second time,
not remembering it all from the first time.

If history is any guide, just moving to a newer base gcc will no
doubt break several things in m3gdb, and I'll probably be the logical
one to do most of that part of the patching.


Jay K wrote:
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  
>  
>  
> and/or
>  
>  
>  
>  
>  - Can someone show me how the above translates to C?
>    Or Modula-3 with no nested functions.
>    Using Modula-3 closures.
>    It's not about the syntax, it's about a lower level model.
>    Bonus points if you can show me the translation to C-like code with gcc trampolines also.
>      That's mainly currently just for curiosity.
>  
>  
>  
> and/or
>  
>  
>  
>  - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
>  
>  
>  
> Like, I need to understand what to do for gcc 4.5.0.
>  
>  
> Some of the tree-nested changes refer to a particular test case.
> I'll look there to start.
>  
>  
>  
> In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
> With a comment that maybe we could do it better.
> The context in 4.5 is vastly different now.
> The 4.3 changes "completely unmergable".
>   I even looked around for somewhere else to put them.
>  
>  
>  
> Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
>  Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
>  
>  
>  
> I'll see if I can get some clues here:
>   http://gcc.gnu.org/onlinedocs/gccint/
>  
>  
> :)
>  
>  
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> Date: Fri, 28 May 2010 18:07:20 -0400
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>>
>>> Jay K wrote:
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>>
>>>>>
>>>>>
>>>>> We should endeavour to use the same functionality that the C compiler
>>>>> uses for its own nested functions,
>>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> Right..for those that don't know..
>>>>
>>>>
>>>> There's no "good" efficient way to implement nested functions.
>>>> Our implementation is pretty "bad".
>>>> gcc's implementation is pretty "bad".
>>> I think this is far too critical. The inefficiencies you see are
>>> minor. Certainly no worse than the implementation of dispatching
>>> methods of objects, something the world is gaga about.
>> Sufficiently gaga that hardware manufacturers are trying to make it
>> really fast. Things like fetch- and branch- prediction.
>>
>> We may as well use them if there isn't something better around.
>>
>> -- hendrik 		 	   		  


From jay.krell at cornell.edu  Sun May 30 09:45:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 07:45:38 +0000
Subject: [M3devel] closure marker
In-Reply-To: <4C017863.2070209@lcwb.coop>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>,
	, , <4BFDACC6.6020600@lcwb.coop>, ,
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>, ,
	<4BFF18CA.5070107@lcwb.coop>,
	<COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>,
	<4C017863.2070209@lcwb.coop>
Message-ID: <COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>


> On the target in question, native word is 64 bits. Closures are three words, as
> usual, all 64-bits and aligned to 64 bits.

Right.
Though I think for IA64 we might need 128bit marker.
?At least that is the easy conclusion barring deeper understanding.


> The problem comes from the fact that, on this target, the first instruction of
> the code of a procedure is not necessarily aligned to 64 bit.


Right.


> So, when you have a parameter of procedure type, you can't immediately test
> whether it points to a closure marker, because if not, it might be a code address
> that is not a multiple of 8 bytes, and the attempt to test for the entire 64-bit
> marker would suffer an alignment fault.


Right.
I've seen these alignment faults doing several ports.
But now we all know, so maybe not a big deal.


> So, the generated code first tests whether it is a multiple of 8. If not, that
> means it points directly to code. If so, it still could point to either code or
> a closure, but now testing for the marker will not alignment-fault. And it is
> the first test you want to eliminate, right?


Right.


> And your proposal is to code the marker test to only check a 32-bit half word
> for all ones. This will work for code addresses that are not multiples of 8,
> but will still require them to be multiples of 4.


Right.
Admited, initially I forgot about the "rest" of the closure, so didn't
allow for the extra in what I said.


> If Target.Aligned_procedures=FALSE really means they are not necessarily 8-byte aligned,
> but are necessarily 4-byte aligned, which you need, then I think it is misnamed.
> To me, and I think about anybody, I would expect Aligned_procedures=FALSE to mean
> they are not aligned at all. What does it actually mean, for various targets with
> various native word sizes?


Right -- the name is wierd, but hard to come up with another.
It means: can an integer-sized read from a function pointer possibly generate an alignment exception.
Inverted.
For example. on all x86 and AMD64 targets, it is true. Because none of them ever generate
alignment faults (maybe for SSE stuff, irrelevant).


On most/all 32bit targets is also true, because instructions are often guaranteed 4 byte aligned.


?> One approach would be to just make all first instructions of procedures be on
?> 8-byte boundaries.


That might not be trivial.
C code matters too.
It can also be size-wasteful, but often speed-optimizing.


?> Aligned_procedures would be TRUE, and the extra code would
> not be generated. Actually, it is hard for me to imagine a modern object module
> format and linker the did not ensure this, as I understand that usually, linkers
> can selectively remove unreferenced procedures. This would require the code of
> every procedure to be in a separate "section" or whatever, which would then mean
> it would be maximally aligned.


All modern systems (can) remove unused functions.
Surprisingly I don't think this is always/often the default.
In Visual C++ you have to use the -Gy flag to the compiler.
But that doesn't imply anything about alignment.
Maybe you are confusing some concepts?
For example on Win32, executables have "sections".


e.g. .text, .data, .rdata.


By "conceptual reverse engineering", I claim that "sections" exist in order to apply
different page attributes to parts of code/data. That is, read only data and writable
data must be on different pages, if the read onliness is to actually exist and be hardware-enforced.


Therefore, whichever of the two, readonly/writable, comes second, must be page aligned,
in order to not be on the same page as the previous.


On modern systems that have a page attribute "executable", code must also be separate from
read only data.


This does *not* relate to any sort of alignment of functions (except maybe the first function
in an .exe/.dll, maybe).


Sections can also be a crude tool to influence layout and improve locality.
For example the data needed to handle exceptions might be in its own section, in order
to keep it "far away" from everything else, since it is rarely accessed.
Even though it generally just as well be part of read only data.
This way "everything else" is denser and fits on fewer pages.


Size and density are the generally dominant performance factors in most systems.
Touching the disk to page in stuff is among the slowest operations by far, so
reducing size, in order to reduce the number of pages touched, is important.
? Bigger code that is deemed "faster" is rarely preferred.
? Smaller code is also preferred in "embedded" systems.

Anyway..


> Another would be to ascertain that, in the targets where NOT Aligned_procedures,
> a byte containing 16_FF can not be the first byte of any opcode.
> If so, you? could just have the marker check test only one byte. (But still build markers
> the full length, just for consistency.)


No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
I'm not willing to make that bet.
Even the notion of 4 or 8 byte -1 I find tenuous.
You cannot portably/easily guarantee that such bytes aren't valid/existant code.
You must research all the various architecture encodings.
? Granted, we are only talking about function prologues..
The longer the sequence, the statistically less likely it is valid or existant code.
And there is a limit, per-architecture.
Many architectures have fixed length instructions.
On such architectures, going beyond that length does not change the odds of validity,
though does change the odds of existance (if valid). But our hope is really for invalidity,
not mere non-existance.


> Lacking any of the above, I'd just leave the extra code in there.


Yeah, it's not as much as I had thougt.
I was thinking it generated code to read the bytes piecemeal or something.


Again though, my real goal is to try to remove platform-specificity.
Something that can be made true for all architectures with no downside, should be made so,
and the variable removed.


I think even the current scheme maybe invalid for IA64.
We should probably have ClosureMarkerSizeStored and ClosureMarkerSizeChecked.
?


Except for IA64 and possibly SH, ClosureMarkerSizeStored should be sizeof(INTEGER) and ClosureMarkerSizeChecked would be 4.


The nice property there is that, barring existance of IA64 and SH, we would remove the target-specificity entirely,
and m3gdb would be unchanged. IA64 and SH might work, not sure.
I do have two IA64 machines and a Dreamcast, but...


I'd also like to understand what this all might look like with a portable C generating backend.
Clearly, reasonably the generated code might need to be able to say:
?#if WORD_SIZE == 4 
?#if ENDIAN == LITTLE_ENDIAN 


but hopefully not much else.
And maybe not even those. :)


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sun May 30 11:47:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 09:47:21 +0000
Subject: [M3devel] the slightly difficult to merge parts 4.3 vs. 4.5
Message-ID: <COL101-W641326A298A33186042008E6ED0@phx.gbl>


--- /src/orig/gcc-4.3.0/gcc/tree-gimple.c??? 2007-12-13 13:49:09.000000000 -0800
+++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-gimple.c??? 2010-05-09 22:27:56.000000000 -0700
@@ -74,6 +74,7 @@
???? case VECTOR_CST:
???? case OBJ_TYPE_REF:
???? case ASSERT_EXPR:
+??? case STATIC_CHAIN_EXPR:
?????? return true;
?
???? default:


That is in is gimple_formal_tmp_rhs, which no longer exists, but which the various
callers do. One obvious guess is callers should each check for STATIC_CHAIN_EXPR.



tree-nested.c:
+??? case STATIC_CHAIN_EXPR:
+????? decl = TREE_OPERAND (t, 0);
+????? target_context = decl_function_context (decl);
+????? if (target_context)
+??? {
+??? ? if (info->context == target_context)
+??? ??? {
+??? ????? /* Make sure frame_decl gets created.? */
+??? ????? (void) get_frame_type (info);
+??? ??? }
+??? ? *tp = get_static_chain (info, target_context, &wi->tsi);
+??? }
+????? else
+??? *tp = null_pointer_node;
+????? break;
+


That is in convert_call_expr.
Which is now called convert_gimple_call, but which is significantly different.
Hm..I see...there is a new gimple.def, similar to tree.def..

Maybe just have to put STATIC_CHAIN_EXPR in there instead, or
put a form in each.

?- Jay

 		 	   		  

From hendrik at topoi.pooq.com  Sun May 30 08:56:47 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 30 May 2010 02:56:47 -0400
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>
References: <4C017863.2070209@lcwb.coop>
	<COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>
Message-ID: <20100530065647.GA21438@topoi.pooq.com>

On Sun, May 30, 2010 at 07:45:38AM +0000, Jay K wrote:
> 
> > On the target in question, native word is 64 bits. Closures are three words, as
> > usual, all 64-bits and aligned to 64 bits.
> 
> Right.
> Though I think for IA64 we might need 128bit marker.
> ?At least that is the easy conclusion barring deeper understanding.
> 
...
...
> 
> 
> Size and density are the generally dominant performance factors in most systems.
> Touching the disk to page in stuff is among the slowest operations by far, so
> reducing size, in order to reduce the number of pages touched, is important.
> ? Bigger code that is deemed "faster" is rarely preferred.
> ? Smaller code is also preferred in "embedded" systems.
> 
...
...> 
> No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
> I'm not willing to make that bet.
> Even the notion of 4 or 8 byte -1 I find tenuous.
> You cannot portably/easily guarantee that such bytes aren't valid/existant code.
> You must research all the various architecture encodings.
> ? Granted, we are only talking about function prologues..
> The longer the sequence, the statistically less likely it is valid or existant code.
> And there is a limit, per-architecture.
> Many architectures have fixed length instructions.
> On such architectures, going beyond that length does not change the odds of validity,
> though does change the odds of existance (if valid). But our hope is really for invalidity,
> not mere non-existance.
> 
...
...
> 
> Again though, my real goal is to try to remove platform-specificity.
> Something that can be made true for all architectures with no downside, should be made so,
> and the variable removed.
> 
> 
> I'd also like to understand what this all might look like with a portable C generating backend.
> Clearly, reasonably the generated code might need to be able to say:
> ?#if WORD_SIZE == 4 
> ?#if ENDIAN == LITTLE_ENDIAN 
> 
> 
> but hopefully not much else.
> And maybe not even those. :)
> 
> 
> ?- Jay
>  		 	   		  
If you can't find a bit pattern that's code on all architectures, 
neither as code address or as instructions, and you insist on being 
completely target-independent, the only solution I see is to make 
procedure addresses into two-word objects.  Instead of using the pointer 
to the code as procedure address, you use the two-word closure as 
procedure address, and copy those two words around as the address of a 
procedure.  For top-level procedures, use NIL as the environment poi 
ter.

I was really surprised when I discovered that Modula 3 didn't do it this 
way.

It's really a trade-off between data size (procedure pointers being 
bigger) and code size (procedure calls should be fast and avoid a lot of 
run-time checks) 

What does gcc use for the addresses of nested procedures?  Does it 
generate code dynamically on the stack or heap to make it fit into one 
word?

Oh.  There's also a compatibility issue.  To what extent are we 
constrained to use the same coding as C for procedure addresses?

-- hendrik


From jay.krell at cornell.edu  Sun May 30 13:45:36 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 11:45:36 +0000
Subject: [M3devel] the slightly difficult to merge parts 4.3 vs. 4.5
In-Reply-To: <COL101-W641326A298A33186042008E6ED0@phx.gbl>
References: <COL101-W641326A298A33186042008E6ED0@phx.gbl>
Message-ID: <COL101-W9FB75D787ADC38A9E21F1E6ED0@phx.gbl>


I'm understanding this a bit more.
The process of converting "generic" trees to "gimple" seems to have changed a bunch.
The set of tree opcodes and gimple opcodes are now completely seperate I believe -- gimple.def is new.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Sun, 30 May 2010 09:47:21 +0000
> Subject: [M3devel] the slightly difficult to merge parts 4.3 vs. 4.5
>
>
> --- /src/orig/gcc-4.3.0/gcc/tree-gimple.c    2007-12-13 13:49:09.000000000 -0800
> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-gimple.c    2010-05-09 22:27:56.000000000 -0700
> @@ -74,6 +74,7 @@
>      case VECTOR_CST:
>      case OBJ_TYPE_REF:
>      case ASSERT_EXPR:
> +    case STATIC_CHAIN_EXPR:
>        return true;
>
>      default:
>
>
> That is in is gimple_formal_tmp_rhs, which no longer exists, but which the various
> callers do. One obvious guess is callers should each check for STATIC_CHAIN_EXPR.
>
>
>
> tree-nested.c:
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
>
>
> That is in convert_call_expr.
> Which is now called convert_gimple_call, but which is significantly different.
> Hm..I see...there is a new gimple.def, similar to tree.def..
>
> Maybe just have to put STATIC_CHAIN_EXPR in there instead, or
> put a form in each.
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Sun May 30 13:44:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 11:44:29 +0000
Subject: [M3devel] closure marker
In-Reply-To: <20100530065647.GA21438@topoi.pooq.com>
References: <4C017863.2070209@lcwb.coop>,
	<COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>,
	<20100530065647.GA21438@topoi.pooq.com>
Message-ID: <COL101-W29F2F362A57035BBF95F02E6ED0@phx.gbl>


gcc generates code on the stack.
?Which Tony and I both don't like.
? I think you could change it to generate on an executable heap though -- after all, Java and C# do still work.
? And ATL even does this, to get the this pointer to a WindowProc.


We could use a per-target marker if necessary.


We do pass function pointers to C -- window procs, thread entry.
However, we could handled through a little glue code.


As well, we could disallow passing function pointers to <* external *> functions.
Or taking the address of <* external *> functions.


So interesting idea then -- change procedure pointers to be two words, function pointer and static link?
?Too inefficient? Too incompatible? Too big of a change?


Actually toplevel could benefit from non-null static link, for the sake of position independence.
Some C calling conventions do this sort of thing.


?- Jay


----------------------------------------
> Date: Sun, 30 May 2010 02:56:47 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
> On Sun, May 30, 2010 at 07:45:38AM +0000, Jay K wrote:
>>
>>> On the target in question, native word is 64 bits. Closures are three words, as
>>> usual, all 64-bits and aligned to 64 bits.
>>
>> Right.
>> Though I think for IA64 we might need 128bit marker.
>>  At least that is the easy conclusion barring deeper understanding.
>>
> ...
> ...
>>
>>
>> Size and density are the generally dominant performance factors in most systems.
>> Touching the disk to page in stuff is among the slowest operations by far, so
>> reducing size, in order to reduce the number of pages touched, is important.
>>   Bigger code that is deemed "faster" is rarely preferred.
>>   Smaller code is also preferred in "embedded" systems.
>>
> ...
> ...>
>> No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
>> I'm not willing to make that bet.
>> Even the notion of 4 or 8 byte -1 I find tenuous.
>> You cannot portably/easily guarantee that such bytes aren't valid/existant code.
>> You must research all the various architecture encodings.
>>   Granted, we are only talking about function prologues..
>> The longer the sequence, the statistically less likely it is valid or existant code.
>> And there is a limit, per-architecture.
>> Many architectures have fixed length instructions.
>> On such architectures, going beyond that length does not change the odds of validity,
>> though does change the odds of existance (if valid). But our hope is really for invalidity,
>> not mere non-existance.
>>
> ...
> ...
>>
>> Again though, my real goal is to try to remove platform-specificity.
>> Something that can be made true for all architectures with no downside, should be made so,
>> and the variable removed.
>>
>>
>> I'd also like to understand what this all might look like with a portable C generating backend.
>> Clearly, reasonably the generated code might need to be able to say:
>>  #if WORD_SIZE == 4
>>  #if ENDIAN == LITTLE_ENDIAN
>>
>>
>> but hopefully not much else.
>> And maybe not even those. :)
>>
>>
>>  - Jay
>>
> If you can't find a bit pattern that's code on all architectures,
> neither as code address or as instructions, and you insist on being
> completely target-independent, the only solution I see is to make
> procedure addresses into two-word objects. Instead of using the pointer
> to the code as procedure address, you use the two-word closure as
> procedure address, and copy those two words around as the address of a
> procedure. For top-level procedures, use NIL as the environment poi
> ter.
>
> I was really surprised when I discovered that Modula 3 didn't do it this
> way.
>
> It's really a trade-off between data size (procedure pointers being
> bigger) and code size (procedure calls should be fast and avoid a lot of
> run-time checks)
>
> What does gcc use for the addresses of nested procedures? Does it
> generate code dynamically on the stack or heap to make it fit into one
> word?
>
> Oh. There's also a compatibility issue. To what extent are we
> constrained to use the same coding as C for procedure addresses?
>
> -- hendrik
 		 	   		  

From jay.krell at cornell.edu  Sun May 30 20:11:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 18:11:26 +0000
Subject: [M3devel] optimizer doesn't do much?
Message-ID: <COL101-W38377DF1B65EBB708E2D6FE6ED0@phx.gbl>


This little function:


PROCEDURE CallProcx (p: FinallyProc;? VAR a: RT0.RaiseActivation) RAISES ANY =
? BEGIN
??? p (a);
? END CallProcx;


generates all of this at -O2 and above:


_RTExFrame__CallProcx:
??? pushq??? %rbp
??? movq??? %rsp, %rbp
??? subq??? $32, %rsp
???? movq??? %rdi, -24(%rbp)
??? movq??? %rsi, -32(%rbp)
??? movq??? -24(%rbp), %rax ; why not just use %rdi?
??? movq??? %rax, -8(%rbp)
??? movq??? -8(%rbp), %rax ; why? It just stored it!
??? testq??? %rax, %rax
??? je??? L2 ; huh? Compare to NIL, then then just call it anyway?
??? movq??? -8(%rbp), %rax ; why? Again, it is already there.
??? cmpq??? $-1, (%rax)
??? jne??? L2
??? movq??? -8(%rbp), %rax ; why? Again, it is already there.
??? movq??? 16(%rax), %rax
??? movq??? %rax, -16(%rbp)
??? movq??? -8(%rbp), %rax ; again! yeah %rax got clobbered,
??? ?????????????????????? ; but surely it could be using
??? ?????????????????????? ; a different register?
??? movq??? 8(%rax), %rax
??? movq??? %rax, -8(%rbp)
L2:
??? movq??? -8(%rbp), %rax? ; and again
??? movq??? -32(%rbp), %rdi ; %rsi still has it..
??? movq??? -16(%rbp), %r10
??? call??? *%rax
??? leave
??? ret


it is even worse if you omit RAISES ANY.
RAISES ANY saves it from calling pushframe.
and shouldn't it be calling fault_proc for NIL?


Here is what similar C code gets me:
Is this a fair comparison?


typedef void (*F1)(void* chain, void* activation);

typedef struct {
??? long marker;
??? F1 f1;
??? void* chain;
} Closure_t;


void call_F1(Closure_t* cl, void* activation)
{
??? if (cl->marker == -1)
??????? cl->f1(cl->chain, activation);
??? else
??????? ((F1)cl)(0, activation);
}


_call_F1:
??? pushl??? %ebp
??? movl??? %esp, %ebp
??? movl??? 8(%ebp), %ecx
??? movl??? 12(%ebp), %eax
??? cmpl??? $-1, (%ecx)
??? je??? L7
??? movl??? %eax, 12(%ebp)
??? movl??? $0, 8(%ebp)
??? leave
??? jmp??? *%ecx
??? .align 4,0x90
L7:
??? movl??? 8(%ecx), %eax
??? movl??? %eax, 8(%ebp)
??? movl??? 4(%ecx), %ecx
??? leave
??? jmp??? *%ecx


.err..oops different processor:


_call_F1:
??? pushq??? %rbp
??? cmpq??? $-1, (%rdi)
??? movq??? %rdi, %rax
??? movq??? %rsp, %rbp
??? je??? L7
??? xorl??? %edi, %edi
??? movq??? %rax, %r11
??? leave
??? jmp??? *%r11
L7:
??? movq??? 16(%rdi), %rdi
??? movq??? 8(%rax), %r11
??? leave
??? jmp??? *%r11


I don't always care, at least it works, but it does seem surprisingly bad.


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Mon May 31 02:34:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 00:34:32 +0000
Subject: [M3devel] more flailing on STATIC_CHAIN_EXPR
Message-ID: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>


so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
? Not sure the generated code is correct yet, haven't run it.
? I'll keep digging esp. on the existing errors.


However I'm still a bit "confused".


What is the point of STATIC_CHAIN_EXPR?


I still have to try the man/boy example, sorry and thank you.


Back to the question of STATIC_CHAIN_EXPR.


I can see it used in tree-nested.
So it doesn't seem pointless.


However, notice the following:
?gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
?It knows the function is nested. It figures out what references resolve how.
? Locals that are referenced by a nested function are put in a local struct.
? Sometimes by value, sometimes by pointer, depending.
? Non-local references go through the chain, n levels, etc.
? I believe it figures out itself to pass the static link.
? It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.


Now, the parts that I recognize are less automatic:
? static link use can't be optimized away, because it is part of function pointer equality.
? That is what some of our changes to tree-nested are about.
? Furthermore, if it can't be optimized away, it might also be forced to exist in the first place. 
?? Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
? 

The part in 4.5 that says:
DECL_STATIC_CHAIN (decl) = 0;


should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
we can reliably set it in parse.c.


One thing I'm sure I'm missing though is indirect calls.
>From gcc's point of view, indirect calls never? have a static link?
And from ours they always do?
??


This must be key. Direct nested calls need no special support. 
? So a lot will just work.
And all indirect calls need special support, since they might be to a closure.
?


I'll keep trying to understand.


I can get stuff to compile by having m3cg_load_static_link just push nul.
? Feels wrong though. I have to look at the code, but in the RtExFrame example, 
?? it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
?? seems to contain an extra.
When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
wierd behavior like compiler hanging, busy growing arrays very large.


If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
at least to make it go away, else gimplification reasonably complains that it doesn't
know what to do with it.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon May 31 10:26:41 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 31 May 2010 04:26:41 -0400
Subject: [M3devel] more flailing on STATIC_CHAIN_EXPR
In-Reply-To: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>
References: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>
Message-ID: <4521E50B-DF20-467A-B0CC-C5D97D83A42A@cs.purdue.edu>

I suggest you play around with various nested procedure sources and see what code is generated for static chains to understand what is going on.  It has been a long while since I looked at this code and I don't remember all the details.  If I had some time I could probably dredge it up.  But the important thing is that we need to be able to build procedure closures so we need some way to reify the static chain for a procedure.  That's why we need an explicit EXPR.

On 30 May 2010, at 20:34, Jay K wrote:

> 
> so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
>   Not sure the generated code is correct yet, haven't run it.
>   I'll keep digging esp. on the existing errors.
> 
> 
> However I'm still a bit "confused".
> 
> 
> What is the point of STATIC_CHAIN_EXPR?
> 
> 
> I still have to try the man/boy example, sorry and thank you.
> 
> 
> Back to the question of STATIC_CHAIN_EXPR.
> 
> 
> I can see it used in tree-nested.
> So it doesn't seem pointless.
> 
> 
> However, notice the following:
>  gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
>  It knows the function is nested. It figures out what references resolve how.
>   Locals that are referenced by a nested function are put in a local struct.
>   Sometimes by value, sometimes by pointer, depending.
>   Non-local references go through the chain, n levels, etc.
>   I believe it figures out itself to pass the static link.
>   It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.
> 
> 
> Now, the parts that I recognize are less automatic:
>   static link use can't be optimized away, because it is part of function pointer equality.
>   That is what some of our changes to tree-nested are about.
>   Furthermore, if it can't be optimized away, it might also be forced to exist in the first place. 
>    Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
>   
> 
> The part in 4.5 that says:
> DECL_STATIC_CHAIN (decl) = 0;
> 
> 
> should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
> we can reliably set it in parse.c.
> 
> 
> One thing I'm sure I'm missing though is indirect calls.
>> From gcc's point of view, indirect calls never? have a static link?
> And from ours they always do?
> ??
> 
> 
> This must be key. Direct nested calls need no special support. 
>   So a lot will just work.
> And all indirect calls need special support, since they might be to a closure.
> ?
> 
> 
> I'll keep trying to understand.
> 
> 
> I can get stuff to compile by having m3cg_load_static_link just push nul.
>   Feels wrong though. I have to look at the code, but in the RtExFrame example, 
>    it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
>    seems to contain an extra.
> When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
> wierd behavior like compiler hanging, busy growing arrays very large.
> 
> 
> If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
> at least to make it go away, else gimplification reasonably complains that it doesn't
> know what to do with it.
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Mon May 31 10:37:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 08:37:26 +0000
Subject: [M3devel] more flailing on STATIC_CHAIN_EXPR
In-Reply-To: <4521E50B-DF20-467A-B0CC-C5D97D83A42A@cs.purdue.edu>
References: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>,
	<4521E50B-DF20-467A-B0CC-C5D97D83A42A@cs.purdue.edu>
Message-ID: <COL101-W9E39A755BF969730EFD1FE6EE0@phx.gbl>


Ah. That little clue does help.

gcc notices which locals are used in nested functions.
gcc puts those (or pointers to them) in a local struct.
We want the address of that struct so we can store it elsewhere, in our closure.
? (gcc would store it in a trampoline.)


I do have try some small samples, and compile with cm3cg -y..

Thanks,
?- Jay

----------------------------------------
> Subject: Re: [M3devel] more flailing on STATIC_CHAIN_EXPR
> From: hosking at cs.purdue.edu
> Date: Mon, 31 May 2010 04:26:41 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I suggest you play around with various nested procedure sources and see what code is generated for static chains to understand what is going on. It has been a long while since I looked at this code and I don't remember all the details. If I had some time I could probably dredge it up. But the important thing is that we need to be able to build procedure closures so we need some way to reify the static chain for a procedure. That's why we need an explicit EXPR.
>
> On 30 May 2010, at 20:34, Jay K wrote:
>
>>
>> so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
>> Not sure the generated code is correct yet, haven't run it.
>> I'll keep digging esp. on the existing errors.
>>
>>
>> However I'm still a bit "confused".
>>
>>
>> What is the point of STATIC_CHAIN_EXPR?
>>
>>
>> I still have to try the man/boy example, sorry and thank you.
>>
>>
>> Back to the question of STATIC_CHAIN_EXPR.
>>
>>
>> I can see it used in tree-nested.
>> So it doesn't seem pointless.
>>
>>
>> However, notice the following:
>> gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
>> It knows the function is nested. It figures out what references resolve how.
>> Locals that are referenced by a nested function are put in a local struct.
>> Sometimes by value, sometimes by pointer, depending.
>> Non-local references go through the chain, n levels, etc.
>> I believe it figures out itself to pass the static link.
>> It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.
>>
>>
>> Now, the parts that I recognize are less automatic:
>> static link use can't be optimized away, because it is part of function pointer equality.
>> That is what some of our changes to tree-nested are about.
>> Furthermore, if it can't be optimized away, it might also be forced to exist in the first place.
>> Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
>>
>>
>> The part in 4.5 that says:
>> DECL_STATIC_CHAIN (decl) = 0;
>>
>>
>> should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
>> we can reliably set it in parse.c.
>>
>>
>> One thing I'm sure I'm missing though is indirect calls.
>>> From gcc's point of view, indirect calls never? have a static link?
>> And from ours they always do?
>> ??
>>
>>
>> This must be key. Direct nested calls need no special support.
>> So a lot will just work.
>> And all indirect calls need special support, since they might be to a closure.
>> ?
>>
>>
>> I'll keep trying to understand.
>>
>>
>> I can get stuff to compile by having m3cg_load_static_link just push nul.
>> Feels wrong though. I have to look at the code, but in the RtExFrame example,
>> it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
>> seems to contain an extra.
>> When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
>> wierd behavior like compiler hanging, busy growing arrays very large.
>>
>>
>> If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
>> at least to make it go away, else gimplification reasonably complains that it doesn't
>> know what to do with it.
>>
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Mon May 31 10:44:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 08:44:27 +0000
Subject: [M3devel] m3cc -enable-checking=all
Message-ID: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>


????? Configure = Configure & " -enable-checking=all"


enables a bunch of extra checks.
That fail.
With the current 4.3 backend.
I'm going to look into some/all of this.


.1079 = D.1078 & 1
../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
word_64

int_64

int_64

D.1101 = D.1100 & 1
../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
word_64

int_64

int_64

D.1121 = D.1120 & 1
../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
word_64


I think this might be one and only one problem.
The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.

Probably positive constants that fit in the signed type of the same size shouldn't fail.

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Mon May 31 11:50:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 09:50:59 +0000
Subject: [M3devel] m3cc -enable-checking=all
In-Reply-To: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>
References: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>
Message-ID: <COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>


static void
m3cg_and (void)
{
? MTYPE (t);

? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t),
???????????????????????????? EXPR_REF (-2), EXPR_REF (-1));
? EXPR_POP ();
}


Why do we make the result unsigned?

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Mon, 31 May 2010 08:44:27 +0000
> Subject: [M3devel] m3cc -enable-checking=all
>
>
>       Configure = Configure & " -enable-checking=all"
>
>
> enables a bunch of extra checks.
> That fail.
> With the current 4.3 backend.
> I'm going to look into some/all of this.
>
>
> .1079 = D.1078 & 1
> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
> word_64
>
> int_64
>
> int_64
>
> D.1101 = D.1100 & 1
> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
> word_64
>
> int_64
>
> int_64
>
> D.1121 = D.1120 & 1
> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
> word_64
>
>
> I think this might be one and only one problem.
> The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.
>
> Probably positive constants that fit in the signed type of the same size shouldn't fail.
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Mon May 31 12:32:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 10:32:43 +0000
Subject: [M3devel] m3cc -enable-checking=all
In-Reply-To: <COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
References: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>,
	<COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
Message-ID: <COL101-W1AB0D899A46A9622B7612E6EE0@phx.gbl>


-enable_checking=all does find more serious seeming stuff once the noise of int & int => word is removed:


static void
m3cg_pop (void)
{
? UNUSED_MTYPE (t);

? if (TREE_SIDE_EFFECTS (t))
??? add_stmt (EXPR_REF (-1));
? EXPR_POP ();
}


intent was presumably:

static void
m3cg_pop (void)
{
? UNUSED_MTYPE (t);
? tree a = EXPR_REF (-1);

? if (TREE_SIDE_EFFECTS (a))
??? add_stmt (a);
? EXPR_POP ();
}

alas..
introduced I think by rev 1.18 in 2006.
Previously we always set side_effects.


?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Mon, 31 May 2010 09:50:59 +0000
> Subject: Re: [M3devel] m3cc -enable-checking=all
>
>
> static void
> m3cg_and (void)
> {
>   MTYPE (t);
>
>   EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t),
>                              EXPR_REF (-2), EXPR_REF (-1));
>   EXPR_POP ();
> }
>
>
> Why do we make the result unsigned?
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Mon, 31 May 2010 08:44:27 +0000
>> Subject: [M3devel] m3cc -enable-checking=all
>>
>>
>> Configure = Configure & " -enable-checking=all"
>>
>>
>> enables a bunch of extra checks.
>> That fail.
>> With the current 4.3 backend.
>> I'm going to look into some/all of this.
>>
>>
>> .1079 = D.1078 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>> D.1101 = D.1100 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>> D.1121 = D.1120 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>>
>>
>> I think this might be one and only one problem.
>> The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.
>>
>> Probably positive constants that fit in the signed type of the same size shouldn't fail.
>>
>> - Jay
>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Mon May 31 12:57:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 10:57:24 +0000
Subject: [M3devel] m3cc/configure -enable-checks=all non-trivial conversion
 at assignment
Message-ID: <COL101-W72E70FC74CFED51C30F64E6EE0@phx.gbl>


configure -enable-checks=all

../src/M3FP.m3:48: error: non-trivial conversion at assignment
word_64
int_64

????? error ("non-trivial conversion at assignment");
????? debug_generic_expr (TREE_TYPE (lhs));
????? debug_generic_expr (TREE_TYPE (rhs));
????? return true;


gcc doesn't like conversion from word64 to int64.

PROCEDURE ExtendByInt (READONLY a: T;? i: Int): T = (* line 48 *)
? VAR buf: NChars;
? BEGIN
??? FOR x := FIRST (buf) TO LAST (buf) DO
????? buf [x] := VAL (Word.And (i, 16_ff), CHAR);
????? i := Word.Shift (i, -8);? (* line 53 *)
??? END;
??? RETURN Fingerprint.FromChars (buf, a);
? END ExtendByInt;


The line is probably the one with the shift.
Int here is ???? Int = BITS 32 FOR [-16_7fffffff - 1 .. 16_7fffffff];

Presumably we should just build a cast?

I'm guessing the problem is:

(180) set_source_line
? source line?? 53
(181) load
? type:int32
? type:int64?? 
? m3cg_load (M3_ENQ7Kn_i): offset 0x0, convert int32 -> int64
(182) load_integer
? type:int64
? integer i:0xfe n_bytes:0x1 0x00000000000000008 sign -1
(183) shift
? type:word64? <== 
(184) import_procedure
? type:void
? procedure:RTHooks__ReportFault nparams:0x2 rettype:void
(185) declare_param
? type:addr
? param M3_AJWxb1_module type 0xb typeid 0x8402063 bytesize 0x40 alignment 0x40 in_memory 0x0 up_level 0x0
? mode 0x11 (DImode)
(186) declare_param
? type:int64
? param M3_AcxOUs_info type 0x7 typeid 0x195c2a74 bytesize 0x40 alignment 0x40 in_memory 0x0 up_level 0x0
? mode 0x11 (DImode)
(187) set_runtime_proc
(188) check_range
? type:int64
? integer i:0xfa n_bytes:0x4 0x00000000080000000 sign -1
? integer i:0xfb n_bytes:0x4 0x0000000007fffffff sign 1
? check range type 0x7 code 0x1
? declare_fault_proc: type is 0x11 (DImode)
(189) store
? type:int64? <==
? type:int32
? store (M3_ENQ7Kn_i) offset 0x0 src_t int64 dst_t int32
(190) set_source_line
?

The line numbers don't seem to be reported correctly -- we just get the first line of the function.

I don't think this is a serious problem, but probably here:

static void
m3cg_shift (void)
{
? MTYPE (t);

? tree n = declare_temp (t_int);
? tree x = declare_temp (t);

? gcc_assert (INTEGRAL_TYPE_P (t));

? add_stmt (m3_build2 (MODIFY_EXPR, t_int, n, EXPR_REF(-1)));
? add_stmt (m3_build2 (MODIFY_EXPR, t, x, EXPR_REF(-2)));


We should cast 1) assert t is unsigned and 2 ) cast x to it.

I will look into why we don't accidentally ever do arithmetic shift, as gcc does overload the same operand based on type:

/* Shift operations for shift and rotate.
?? Shift means logical shift if done on an
?? unsigned type, arithmetic shift if done on a signed type.
?? The second operand is the number of bits to
?? shift by; it need not be the same type as the first operand and result.
?? Note that the result is undefined if the second operand is larger
?? than or equal to the first operand's type size.? */
DEFTREECODE (LSHIFT_EXPR, "lshift_expr", tcc_binary, 2)
DEFTREECODE (RSHIFT_EXPR, "rshift_expr", tcc_binary, 2)
DEFTREECODE (LROTATE_EXPR, "lrotate_expr", tcc_binary, 2)
DEFTREECODE (RROTATE_EXPR, "rrotate_expr", tcc_binary, 2)


er. actually the problem is on output not input?
shift => word64
but then we do int64 => int32 conversion of the result.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon May 31 19:52:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 31 May 2010 13:52:27 -0400
Subject: [M3devel] m3cc -enable-checking=all
In-Reply-To: <COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
References: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>
	<COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
Message-ID: <795CF2DA-5382-4A83-8536-E51FB3343724@cs.purdue.edu>

Good question.  Shouldn't it be type t?

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 31 May 2010, at 05:50, Jay K wrote:

> 
> static void
> m3cg_and (void)
> {
>   MTYPE (t);
> 
>   EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t),
>                              EXPR_REF (-2), EXPR_REF (-1));
>   EXPR_POP ();
> }
> 
> 
> Why do we make the result unsigned?
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Mon, 31 May 2010 08:44:27 +0000
>> Subject: [M3devel] m3cc -enable-checking=all
>> 
>> 
>>      Configure = Configure & " -enable-checking=all"
>> 
>> 
>> enables a bunch of extra checks.
>> That fail.
>> With the current 4.3 backend.
>> I'm going to look into some/all of this.
>> 
>> 
>> .1079 = D.1078 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>> 
>> int_64
>> 
>> int_64
>> 
>> D.1101 = D.1100 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>> 
>> int_64
>> 
>> int_64
>> 
>> D.1121 = D.1120 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>> 
>> 
>> I think this might be one and only one problem.
>> The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.
>> 
>> Probably positive constants that fit in the signed type of the same size shouldn't fail.
>> 
>> - Jay
>> 
>> 
> 		 	   		  

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

From wagner at elegosoft.com  Mon May  3 17:19:16 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 03 May 2010 17:19:16 +0200
Subject: [M3devel] Solaris x86 support
In-Reply-To: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>
Message-ID: <20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>

Quoting Dagobert Michelsen <dam at opencsw.org>:

> Dear sirs,
>
> I would like to know if there is a version of cm3 for Solaris 10 x86
> available or planned.

Please see trac ticket https://projects.elego.de/cm3/ticket/1084.

This is the second request for CM3 on Solaris/x86.

I forwarded the first one to m3devel, but there has been no response
from any developer yet as far as I know.

As this is an open source project with volunteers working on the code,
there is no centrally controlled plan, and schedules often get updated;
however, I've added the request to the 5.9 milestone for the time being.

Let's see if anybody catches this one... please stay tuned :-)

Best regards,

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 May  3 17:59:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 3 May 2010 15:59:10 +0000
Subject: [M3devel] Solaris x86 support
In-Reply-To: <20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>
Message-ID: <COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>


If someone gives me ssh access to a Solaris machine, then I can do it.
It'd also be a good project for almost anyone to try.
Otherwise I'll get to it eventually.

?- Jay

----------------------------------------
> Date: Mon, 3 May 2010 17:19:16 +0200
> From: wagner at elegosoft.com
> To: dam at opencsw.org
> CC: m3devel at elego.de; m3-support at elego.de
> Subject: Re: [M3devel] Solaris x86 support
>
> Quoting Dagobert Michelsen :
>
>> Dear sirs,
>>
>> I would like to know if there is a version of cm3 for Solaris 10 x86
>> available or planned.
>
> Please see trac ticket https://projects.elego.de/cm3/ticket/1084.
>
> This is the second request for CM3 on Solaris/x86.
>
> I forwarded the first one to m3devel, but there has been no response
> from any developer yet as far as I know.
>
> As this is an open source project with volunteers working on the code,
> there is no centrally controlled plan, and schedules often get updated;
> however, I've added the request to the 5.9 milestone for the time being.
>
> Let's see if anybody catches this one... please stay tuned :-)
>
> Best regards,
>
> 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 May  3 18:15:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 3 May 2010 16:15:13 +0000
Subject: [M3devel] Solaris x86 support
In-Reply-To: <23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>
Message-ID: <COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>


jay or jaykrell or jkrell or whatever you want but tell me (and tell me machine name)
and hopefully your machine doesn't allow remote password logins, only ssh
Presumably you have a working cc and/or gcc.
I can make a local per-user one if needed, but I can probably only do that for gcc.
? Oddly the Solaris 10 x86 VM I had partly up this weekend came with gcc but not cc.
? Made me wonder if gcc is the way..

? - Jay

----------------------------------------
> CC: wagner at elegosoft.com; m3devel at elego.de; m3-support at elego.de
> From: dam at opencsw.org
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] Solaris x86 support
> Date: Mon, 3 May 2010 18:07:34 +0200
>
> Hi Jay,
>
> Am 03.05.2010 um 17:59 schrieb Jay K:
>> If someone gives me ssh access to a Solaris machine, then I can do it.
>> It'd also be a good project for almost anyone to try.
>> Otherwise I'll get to it eventually.
>
> Cool. I just need your intended username and ssh public key.
> Additionally,
> it would be nice if I could name your with the project at the usage
> page at
> 
>>
>
> Best regards
>
> -- Dago
>
>>
>> - Jay
>>
>> ----------------------------------------
>>> Date: Mon, 3 May 2010 17:19:16 +0200
>>> From: wagner at elegosoft.com
>>> To: dam at opencsw.org
>>> CC: m3devel at elego.de; m3-support at elego.de
>>> Subject: Re: [M3devel] Solaris x86 support
>>>
>>> Quoting Dagobert Michelsen :
>>>
>>>> Dear sirs,
>>>>
>>>> I would like to know if there is a version of cm3 for Solaris 10 x86
>>>> available or planned.
>>>
>>> Please see trac ticket https://projects.elego.de/cm3/ticket/1084.
>>>
>>> This is the second request for CM3 on Solaris/x86.
>>>
>>> I forwarded the first one to m3devel, but there has been no response
>>> from any developer yet as far as I know.
>>>
>>> As this is an open source project with volunteers working on the
>>> code,
>>> there is no centrally controlled plan, and schedules often get
>>> updated;
>>> however, I've added the request to the 5.9 milestone for the time
>>> being.
>>>
>>> Let's see if anybody catches this one... please stay tuned :-)
>>>
>>> Best regards,
>>>
>>> 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 --------------
A non-text attachment was scrubbed...
Name: id_dsa.pub
Type: application/octet-stream
Size: 600 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100503/6a23a00e/attachment-0002.obj>

From bugs at elego.de  Mon May  3 21:34:44 2010
From: bugs at elego.de (CM3)
Date: Mon, 03 May 2010 19:34:44 -0000
Subject: [M3devel] [CM3] #1085: Trac Tickets get auto-discarded form
 cm3devel mailing list
Message-ID: <052.c12f607bc89a9ab27900ba1cc75174b6@elego.de>

#1085: Trac Tickets get auto-discarded form cm3devel mailing list
--------------------------------+-------------------------------------------
      Reporter:  mand@?         |        Owner:  wagner
          Type:  support        |       Status:  new   
      Priority:  medium         |    Milestone:        
     Component:  misc           |      Version:  none  
      Severity:  non-critical   |     Keywords:        
       Relnote:                 |          Org:        
Estimatedhours:  0              |        Hours:  0     
      Billable:  1              |   Totalhours:  0     
      Internal:  0              |  
--------------------------------+-------------------------------------------
Htr:
Open or modify a ticket


Fix:
- added "bugs at elego.de" to "auto-accept" list
- added "use_public_cc = true" to cm3 trac.ini


Env:


--------------------------------+-------------------------------------------
 - cc'd tickets from the cm3 trac get autodiscarded
 - no error message or reason given in notification mail
 - suspected causes:
     o bugs at elego.de is not amemeber
     o trac notification plugin sends cc's as bcc

-- 
Ticket URL: <http://projects.elego.de/cm3/ticket/1085>
CM3 <http://projects.elego.de/cm3>
Critical Mass Modula3 Compiler


From wagner at elegosoft.com  Tue May  4 10:23:42 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 04 May 2010 10:23:42 +0200
Subject: [M3devel] Fwd: Auto-discard notification
Message-ID: <20100504102342.ndbo7ov33ks8o8w4@mail.elegosoft.com>

FYI

mailed before subscription was processed...

----- Forwarded message from m3devel-bounces at elegosoft.com -----
     Date: Tue, 04 May 2010 09:18:59 +0200
     From: m3devel-bounces at elegosoft.com
Reply-To: m3devel-bounces at elegosoft.com
  Subject: Auto-discard notification
       To: m3devel-owner at elegosoft.com

The attached message has been automatically discarded.

----- End forwarded message -----

Date: Tue, 4 May 2010 09:11:07 +0200 (CEST)
Subject: some questions
From: Maksimiuk Darek <maxy at online.nl>
To: m3devel at elegosoft.com


Dear All,
  During last  weekend I decide to give a try and play with Modula-3  
language/environment.

  I have installed the  cm3 compiler and libraries on my WinXP box as  
well as on this
  little  PowerPC based machine called EFIKA  
(http://www.bplan-gmbh.de/output.php?PAGE_ID=124,
  http://www.bplan-gmbh.de/output.php?PAGE_ID=135). Unfortunately,  
this computer is no longer produced
  but still available in some places for sale.


  To get it working on the EFIKA I had to upgrade my Debian  
distribution from Etch to Lenny, and
  install the cm3  Linux PowerPC binaries. As far as I can tell, the  
whole process went without any glitches.

  This is the most important part (at least for me) - some questions ...

  1. Is there any (non-Reactor based) development environment for M3  
(emacs, eclipse, etc)?
  2. Are there any active projects that use M3?
  3. Did somebody benchmarked the cm3 compiler against C/C++ (I am  
interested in  the fp number crunching speed)?


  On the daily basis, I am using Matlab, Ada95, and ... Active Oberon  
(running A2 operating system from ETHZ).

  Thanks for your help.

  Regards,
    Darek
-- 
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 dabenavidesd at yahoo.es  Tue May  4 23:29:07 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 4 May 2010 21:29:07 +0000 (GMT)
Subject: [M3devel] Fwd: Auto-discard notification
In-Reply-To: <20100504102342.ndbo7ov33ks8o8w4@mail.elegosoft.com>
Message-ID: <326965.34591.qm@web23603.mail.ird.yahoo.com>

Hi:
welcome to M3 world, I think you will not repent of doing it.
About your questions:
1. Yes, there is a simple environment built on top of emacs (M3ide by Michel Dagenais http://www.professeurs.polymtl.ca/michel.dagenais/pkg/m3ide.tg) and Eclipse plugin too (M3clipse by Bert Laverman http://sourceforge.net/projects/m3clipse/) both are open source and would be nice to have some one who can use it.
2. Yes there are, many commercial, for research and open source projects too; a few worth to name here are the scripting VM based programming language UFO waiting for release, in the research arena there are others like the object oriented data base language Galileo and commercial ones there might be several ones but due trademark restrictions to publish their names some are not known.   
3. I have one reference worth to check in the side of the DEC SRC M3 vs. others a kind of idea of what you might want to know but could be outdated
http://www.dogfish.org/chris/papers/bakeoff/bakeoff.pdf
http://www.dogfish.org/chris/papers/bakeoff/bakeoff.tar.gz
In the new side you can always take times of programs and compare equivalent ones with time, though it might good to automate performance tests like the ones in the code above url tarball.

I hope it helps


--- El mar, 4/5/10, Olaf Wagner <wagner at elegosoft.com> escribi?:

> De: Olaf Wagner <wagner at elegosoft.com>
> Asunto: [M3devel] Fwd: Auto-discard notification
> Para: m3devel at elegosoft.com
> Fecha: martes, 4 de mayo, 2010 03:23
> FYI
> 
> mailed before subscription was processed...
> 
> ----- Forwarded message from m3devel-bounces at elegosoft.com
> -----
>     Date: Tue, 04 May 2010 09:18:59 +0200
>     From: m3devel-bounces at elegosoft.com
> Reply-To: m3devel-bounces at elegosoft.com
>  Subject: Auto-discard notification
>       To: m3devel-owner at elegosoft.com
> 
> The attached message has been automatically discarded.
> 
> ----- End forwarded message -----
> 
> Date: Tue, 4 May 2010 09:11:07 +0200 (CEST)
> Subject: some questions
> From: Maksimiuk Darek <maxy at online.nl>
> To: m3devel at elegosoft.com
> 
> 
> Dear All,
>  During last  weekend I decide to give a try and play
> with Modula-3 language/environment.
> 
>  I have installed the  cm3 compiler and libraries on
> my WinXP box as well as on this
>  little  PowerPC based machine called EFIKA (http://www.bplan-gmbh.de/output.php?PAGE_ID=124,
>  http://www.bplan-gmbh.de/output.php?PAGE_ID=135).
> Unfortunately, this computer is no longer produced
>  but still available in some places for sale.
> 
> 
>  To get it working on the EFIKA I had to upgrade my Debian
> distribution from Etch to Lenny, and
>  install the cm3  Linux PowerPC binaries. As far as I
> can tell, the whole process went without any glitches.
> 
>  This is the most important part (at least for me) - some
> questions ...
> 
>  1. Is there any (non-Reactor based) development
> environment for M3 (emacs, eclipse, etc)?
>  2. Are there any active projects that use M3?
>  3. Did somebody benchmarked the cm3 compiler against C/C++
> (I am interested in  the fp number crunching speed)?
> 
> 
>  On the daily basis, I am using Matlab, Ada95, and ...
> Active Oberon (running A2 operating system from ETHZ).
> 
>  Thanks for your help.
> 
>  Regards,
>    Darek
> --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 May  6 12:17:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 6 May 2010 10:17:43 +0000
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
 Sun cc vs. GNU cc?
In-Reply-To: <C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
Message-ID: <COL101-W178B634DF437CD791F310AE6F50@phx.gbl>


I thought I had sent a followup on this:
 https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html


Can you suggest precise platform name and precise other decisions?


This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
The provided machine's readme says we have Solaris 8, 9, 10 machines,
with multiple versions of Sun and GNU compilers.


Do I just declare that we only support Sun compiler?
Anyone who for some reason wants GNU gets to "rewrite" the config file and keep it to himself?
Or we somehow provide Sun and GNU "configurations" and user can pick one?


Do we have I386_SOLARIS_SUNCC and I386_SOLARIS_GNUCC?
or I386_SOLARIS_CC and I386_SOLARIS_GCC?

or I386_SOLARIS_SUN and I386_SOLARIS_GNU?




I wouldn't mind "helping" people and author the gcc support in quake.
  With some plan to move quake into cm3 in future.
But I don't want this to snowball into having to list extra identical platforms everywhere,
as has been the case for SOLsun and SOLgnu.
  Granted, platform-specific code is extremely rare now.


But the "one target, multiple configurations" of NT386/GNU/MINGNU did seem to get too messy/confusing.


 - Jay


From: hosking at cs.purdue.edu
Subject: Re: [M3devel] new target names -- SOLsun vs. SOLgnu?
Date: Sat, 17 Apr 2010 09:09:08 -0400
To: jay.krell at cornell.edu



Sounds reasonable.

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


On 17 Apr 2010, at 06:50, Jay K wrote:If we have targets, say, I386_NT, I386_CYGWIN, I386_MINGW, I386_LINUX, I386_FREEBSD, I386_NETBSD, SPARC32_SOLARIS or SPARC_SOLARIS..how does one capture the SOLsun vs. SOLgnu difference? SPARC32_SOLARIS_SUN vs. SPARC32_SOLARIS_GNU? SPARC_SOLARIS_SUNCC, SPARC_SOLARIS_GCC?
"target is underscore separated list of relevant names, usually two but not limited to two"?
 
 
Drop SOLgnu and just equate SPARC32_SOLARIS with SOLsun?
Given that the reason for SOLgnu was because cc was not bundled with OS at some point?
  But now gcc and cc are both bundled as I understand!
 
 
Do some sort of autoconfig, sensitive to the CC environment variable?
 That's actually pretty easy and pretty cheap. Not a terrible idea.
 
 
I'm not really pushing hard on this topic, just that I want to cross build Cygwin from non-NT and was hitting minor problems.
Mainly I want to see if Cygwin pthreads works now, now that the hanging test case got "rewritten", so I can drop the SchedulerPosix.m3 file which duplicates content verbatim out of ThreadPThread.m3..
 
 
 - Jay


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

From hosking at cs.purdue.edu  Thu May  6 15:35:26 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 6 May 2010 09:35:26 -0400
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
	Sun cc vs. GNU cc?
In-Reply-To: <COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
Message-ID: <40F00483-654B-4139-827F-5B0A6E466918@cs.purdue.edu>

Is it true that Sun CC is always available on Solaris these days?

On 6 May 2010, at 06:17, Jay K wrote:

> I thought I had sent a followup on this:
>  https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html
> 
> 
> Can you suggest precise platform name and precise other decisions?
> 
> 
> This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
> The provided machine's readme says we have Solaris 8, 9, 10 machines,
> with multiple versions of Sun and GNU compilers.
> 
> 
> Do I just declare that we only support Sun compiler?
> Anyone who for some reason wants GNU gets to "rewrite" the config file and keep it to himself?
> Or we somehow provide Sun and GNU "configurations" and user can pick one?
> 
> 
> Do we have I386_SOLARIS_SUNCC and I386_SOLARIS_GNUCC?
> or I386_SOLARIS_CC and I386_SOLARIS_GCC?
> or I386_SOLARIS_SUN and I386_SOLARIS_GNU?
> 
> 
> I wouldn't mind "helping" people and author the gcc support in quake.
>   With some plan to move quake into cm3 in future.
> But I don't want this to snowball into having to list extra identical platforms everywhere,
> as has been the case for SOLsun and SOLgnu.
>   Granted, platform-specific code is extremely rare now.
> 
> 
> But the "one target, multiple configurations" of NT386/GNU/MINGNU did seem to get too messy/confusing.
> 
> 
>  - Jay
> 
> 
> From: hosking at cs.purdue.edu
> Subject: Re: [M3devel] new target names -- SOLsun vs. SOLgnu?
> Date: Sat, 17 Apr 2010 09:09:08 -0400
> To: jay.krell at cornell.edu
> 
> Sounds reasonable.
> 
> 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 17 Apr 2010, at 06:50, Jay K wrote:
> 
> If we have targets, say, I386_NT, I386_CYGWIN, I386_MINGW, I386_LINUX, I386_FREEBSD, I386_NETBSD, SPARC32_SOLARIS or SPARC_SOLARIS..how does one capture the SOLsun vs. SOLgnu difference? SPARC32_SOLARIS_SUN vs. SPARC32_SOLARIS_GNU? SPARC_SOLARIS_SUNCC, SPARC_SOLARIS_GCC?
> "target is underscore separated list of relevant names, usually two but not limited to two"?
>  
>  
> Drop SOLgnu and just equate SPARC32_SOLARIS with SOLsun?
> Given that the reason for SOLgnu was because cc was not bundled with OS at some point?
>   But now gcc and cc are both bundled as I understand!
>  
>  
> Do some sort of autoconfig, sensitive to the CC environment variable?
>  That's actually pretty easy and pretty cheap. Not a terrible idea.
>  
>  
> I'm not really pushing hard on this topic, just that I want to cross build Cygwin from non-NT and was hitting minor problems.
> Mainly I want to see if Cygwin pthreads works now, now that the hanging test case got "rewritten", so I can drop the SchedulerPosix.m3 file which duplicates content verbatim out of ThreadPThread.m3..
>  
>  
>  - Jay
> 
> 
> 

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

From dam at opencsw.org  Thu May  6 15:51:43 2010
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 6 May 2010 15:51:43 +0200
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
	Sun cc vs. GNU cc?
In-Reply-To: <40F00483-654B-4139-827F-5B0A6E466918@cs.purdue.edu>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
	<40F00483-654B-4139-827F-5B0A6E466918@cs.purdue.edu>
Message-ID: <3B937FEC-0A36-4A04-A943-7F1A1A5756F6@opencsw.org>

Hi Tony,

Am 06.05.2010 um 15:35 schrieb Tony Hosking:
> Is it true that Sun CC is always available on Solaris these days?

It is not bundled with the OS, but it can be downloaded separately for  
free.


Best regards

   -- Dago



From mika at async.async.caltech.edu  Thu May  6 22:01:19 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 06 May 2010 13:01:19 -0700
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS
	Sun cc vs. GNU cc?
In-Reply-To: <COL101-W178B634DF437CD791F310AE6F50@phx.gbl> 
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>
Message-ID: <20100506200119.099571A209B@async.async.caltech.edu>

Jay K writes:
>--_5e9c7792-d671-4ede-8a4b-673a7203ffec_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>I thought I had sent a followup on this:
> https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html
>
>
>Can you suggest precise platform name and precise other decisions?
>
>
>This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
>The provided machine's readme says we have Solaris 8=2C 9=2C 10 machines=2C
>with multiple versions of Sun and GNU compilers.
>
>
>Do I just declare that we only support Sun compiler?
>Anyone who for some reason wants GNU gets to "rewrite" the config file and =
>keep it to himself?
>Or we somehow provide Sun and GNU "configurations" and user can pick one?

Does Sun's cc (or whatever is needed of it to make CM3 work) come free
nowadays?  It used to be a pay package on Solaris.

    Mika


From jay.krell at cornell.edu  Thu May  6 22:13:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 6 May 2010 20:13:07 +0000
Subject: [M3devel] new target names -- SOLsun vs. SOLgnu?
	I386_SOLARIS	Sun cc vs. GNU cc?
In-Reply-To: <20100506200119.099571A209B@async.async.caltech.edu>
References: <COL101-W36D1E1206D55F36DEFB8E3E60D0@phx.gbl>, ,
	<C0670E9B-280B-4641-890D-046A70507BE3@cs.purdue.edu>,
	<COL101-W178B634DF437CD791F310AE6F50@phx.gbl>,
	<20100506200119.099571A209B@async.async.caltech.edu>
Message-ID: <COL101-W455ADF4C96225C281BC2AAE6F50@phx.gbl>


Yes it is free of cost. But maybe people still prefer gcc for some reason?
e.g. they have some Linux/sparc assembly?
or use gcc extensions?
We generally don't do either in the Modula-3 libraries, since we already compile with Sun cc for Sparc.
 
Or for cross build purposes?
 That can be pretty powerful -- building a full gcc+ld cross toolset. I'm using that for VMS currently (for ld you have to use trunk, the support isn't in the latest release). Though binutils/ld/gas support is a little spotty outside of Linux, generally not as much as gcc. And you have to copy the headers/libraries from the target machine.
 
 
 - Jay



----------------------------------------
> To: jay.krell at cornell.edu
> Date: Thu, 6 May 2010 13:01:19 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] new target names -- SOLsun vs. SOLgnu? I386_SOLARIS Sun cc vs. GNU cc?
>
> Jay K writes:
>>--_5e9c7792-d671-4ede-8a4b-673a7203ffec_
>>Content-Type: text/plain; charset="iso-8859-1"
>>Content-Transfer-Encoding: quoted-printable
>>
>>
>>I thought I had sent a followup on this:
>> https://mail.elegosoft.com/pipermail/m3devel/2010-April/006836.html
>>
>>
>>Can you suggest precise platform name and precise other decisions?
>>
>>
>>This is coming up sooner-not-later also for I386_SOLARIS/AMD64_SOLARIS.
>>The provided machine's readme says we have Solaris 8=2C 9=2C 10 machines=2C
>>with multiple versions of Sun and GNU compilers.
>>
>>
>>Do I just declare that we only support Sun compiler?
>>Anyone who for some reason wants GNU gets to "rewrite" the config file and =
>>keep it to himself?
>>Or we somehow provide Sun and GNU "configurations" and user can pick one?
>
> Does Sun's cc (or whatever is needed of it to make CM3 work) come free
> nowadays? It used to be a pay package on Solaris.
>
> Mika 		 	   		  

From peter.mckinna at gmail.com  Sat May  8 06:22:12 2010
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sat, 8 May 2010 14:22:12 +1000
Subject: [M3devel] Compile Options
Message-ID: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>

Hey,

  Using -c to disable library or program generation does not seem to work.
Also how do you turn off debug symbol generation?
And the -O switch doesnt seem to optimise anything.

  Is it just me or the documentation.

Regards

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100508/835dbed7/attachment-0002.html>

From hosking at cs.purdue.edu  Sat May  8 06:55:10 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 8 May 2010 00:55:10 -0400
Subject: [M3devel] Compile Options
In-Reply-To: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
Message-ID: <C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>

What target platform?

On 8 May 2010, at 00:22, Peter McKinna wrote:

> Hey,
> 
>   Using -c to disable library or program generation does not seem to work. Also how do you turn off debug symbol generation?
> And the -O switch doesnt seem to optimise anything.
> 
>   Is it just me or the documentation.
> 
> Regards
> 
> Peter



From jay.krell at cornell.edu  Sat May  8 06:58:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 04:58:40 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
Message-ID: <COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>


-O is the config files
It gets passed on to them and they may or may not pay attention.

Turning off symbol generation not something I'm very sympathetic too.
I realize it cuts I/O, build time, resulting binary size (possibly load/runtime,
depending on the load behavior of symbols). Though on Windows
the symbols go into separate files, greatly reducing any negative affect.
On one hand, you don't want to inhibit debugging,
but on the other, we don't have a good debugger story anyway.
Again, check the config files.

-c I don't know. Is it important?

?- Jay

________________________________
> Date: Sat, 8 May 2010 14:22:12 +1000
> From: peter.mckinna at gmail.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] Compile Options
>
> Hey,
>
> Using -c to disable library or program generation does not seem to work. Also how do you turn off debug symbol generation?
> And the -O switch doesnt seem to optimise anything.
>
> Is it just me or the documentation.
>
>
> Regards
>
> Peter
 		 	   		  

From wagner at elegosoft.com  Sat May  8 12:40:04 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 08 May 2010 12:40:04 +0200
Subject: [M3devel] Compile Options
In-Reply-To: <COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>
Message-ID: <20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>

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

> -O is the config files
> It gets passed on to them and they may or may not pay attention.
>
> Turning off symbol generation not something I'm very sympathetic too.
> I realize it cuts I/O, build time, resulting binary size (possibly   
> load/runtime,
> depending on the load behavior of symbols). Though on Windows
> the symbols go into separate files, greatly reducing any negative affect.
> On one hand, you don't want to inhibit debugging,

Of course you may want to strip symbols for programs delivered to
customers.

> but on the other, we don't have a good debugger story anyway.

m3gdb works well on certain platforms.

> Again, check the config files.
>
> -c I don't know. Is it important?

The front end just includes some quake calls in the generated
m3make file for the options:

% less AMD64_FREEBSD/m3make.args
set_config_options ()
readonly _all = TRUE % cm3 -build
m3_optimize (TRUE)                  <----
m3_debug (TRUE)                     <----
M3_KEEP_FILES = TRUE
m3_compile_only ()                  <----
M3_MODE = "build"
include_dir ("../src")

At least optimize and debug used to work some time ago; I'm not
sure about compile-only.

Was something lost during the great config refactoring?
Can you please check that, Jay?

I think we shold implement the CLI as documented. We _might_ discuss
the value-add of -c (I've never used it).

We're probably missing regression tests for these simple command line
arguments, too.

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  Sat May  8 18:01:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 8 May 2010 12:01:12 -0400
Subject: [M3devel] Compile Options
In-Reply-To: <20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
Message-ID: <EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>

-O used to work in the old config files.
Did it get lost?

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 8 May 2010, at 06:40, Olaf Wagner wrote:

> Quoting Jay K <jay.krell at cornell.edu>:
> 
>> -O is the config files
>> It gets passed on to them and they may or may not pay attention.
>> 
>> Turning off symbol generation not something I'm very sympathetic too.
>> I realize it cuts I/O, build time, resulting binary size (possibly  load/runtime,
>> depending on the load behavior of symbols). Though on Windows
>> the symbols go into separate files, greatly reducing any negative affect.
>> On one hand, you don't want to inhibit debugging,
> 
> Of course you may want to strip symbols for programs delivered to
> customers.
> 
>> but on the other, we don't have a good debugger story anyway.
> 
> m3gdb works well on certain platforms.
> 
>> Again, check the config files.
>> 
>> -c I don't know. Is it important?
> 
> The front end just includes some quake calls in the generated
> m3make file for the options:
> 
> % less AMD64_FREEBSD/m3make.args
> set_config_options ()
> readonly _all = TRUE % cm3 -build
> m3_optimize (TRUE)                  <----
> m3_debug (TRUE)                     <----
> M3_KEEP_FILES = TRUE
> m3_compile_only ()                  <----
> M3_MODE = "build"
> include_dir ("../src")
> 
> At least optimize and debug used to work some time ago; I'm not
> sure about compile-only.
> 
> Was something lost during the great config refactoring?
> Can you please check that, Jay?
> 
> I think we shold implement the CLI as documented. We _might_ discuss
> the value-add of -c (I've never used it).
> 
> We're probably missing regression tests for these simple command line
> arguments, too.
> 
> 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/20100508/f9331286/attachment-0002.html>

From jay.krell at cornell.edu  Sun May  9 00:21:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 22:21:59 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>,
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>,
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>,
	<EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>
Message-ID: <COL101-W4501E007067E4DA24A83D6E6F70@phx.gbl>


-O looks right for the vast majority of targets (Unix.common: *BSD, Solaris, Darwin, Linux, maybe not NT/Interix/Cygwin/VMS).
I'll adjust -g/-gstabs+ (PA64_HPUX never generates symbols currently, since it doesn't support stabs)
I have some more config file cleanup on deck: moving m3back_flags out of per-target and to per-architecture, though even that is necessary duplication


I propose also that -O should imply -O2, not -O3.
?-O2 seems to be heavily used in the wider world, -O3 not so much 
?For one thing, gcc itself defaults to building with -O2.

I have it like this:

if not defined("m3back_optimize")
?m3back_optimize = "-O2"
end

if not defined("m3back_debug")
?
m3back_debug = "-gstaus+"

end


and then
if optimize options += m3back_optimize end
if debug options += m3back_debug? end




individual users/platforms can override, such as PA64_HPUX setting m3back_debug = "" (maybe later to something else)
maybe we can shift to dwarf at some point too, that seems to be the favored format on most platforms


?- Jay



________________________________
> From: hosking at cs.purdue.edu
> Date: Sat, 8 May 2010 12:01:12 -0400
> To: wagner at elegosoft.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compile Options
>
>
>
> -O used to work in the old config files.
> Did it get lost?
>
>
> 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 8 May 2010, at 06:40, Olaf Wagner wrote:
>
> Quoting Jay K>:
>
> -O is the config files
> It gets passed on to them and they may or may not pay attention.
>
> Turning off symbol generation not something I'm very sympathetic too.
> I realize it cuts I/O, build time, resulting binary size (possibly load/runtime,
> depending on the load behavior of symbols). Though on Windows
> the symbols go into separate files, greatly reducing any negative affect.
> On one hand, you don't want to inhibit debugging,
>
> Of course you may want to strip symbols for programs delivered to
> customers.
>
> but on the other, we don't have a good debugger story anyway.
>
> m3gdb works well on certain platforms.
>
> Again, check the config files.
>
> -c I don't know. Is it important?
>
> The front end just includes some quake calls in the generated
> m3make file for the options:
>
> % less AMD64_FREEBSD/m3make.args
> set_config_options ()
> readonly _all = TRUE % cm3 -build
> m3_optimize (TRUE) <----
> m3_debug (TRUE) <----
> M3_KEEP_FILES = TRUE
> m3_compile_only () <----
> M3_MODE = "build"
> include_dir ("../src")
>
> At least optimize and debug used to work some time ago; I'm not
> sure about compile-only.
>
> Was something lost during the great config refactoring?
> Can you please check that, Jay?
>
> I think we shold implement the CLI as documented. We _might_ discuss
> the value-add of -c (I've never used it).
>
> We're probably missing regression tests for these simple command line
> arguments, too.
>
> 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 May  9 00:31:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 22:31:09 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <COL101-W4501E007067E4DA24A83D6E6F70@phx.gbl>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>, ,
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>, ,
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>, ,
	<EEF002D8-5312-4C6C-B0CA-6AE8913F8FB0@cs.purdue.edu>,
	<COL101-W4501E007067E4DA24A83D6E6F70@phx.gbl>
Message-ID: <COL101-W25C8957E8FB3C0461CD852E6F70@phx.gbl>


I assume currently -g can't be turned off, because cm3cfg.common:

proc set_config_options() is
??? m3_option("-why")?? %-- produce a listing that explains what's happening and why
??? m3_debug(TRUE)????? %-- produce object code with debugging symbols
??? M3_OPTIONS += "-w1" %-- produce "level 1" warnings
end

Which was probably always like that but I'm not sure, I only sampled one historical file just now.
We should maybe have -g0 to turn it off?

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; wagner at elegosoft.com
> Date: Sat, 8 May 2010 22:21:59 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compile Options
>
>
> -O looks right for the vast majority of targets (Unix.common: *BSD, Solaris, Darwin, Linux, maybe not NT/Interix/Cygwin/VMS).
> I'll adjust -g/-gstabs+ (PA64_HPUX never generates symbols currently, since it doesn't support stabs)
> I have some more config file cleanup on deck: moving m3back_flags out of per-target and to per-architecture, though even that is necessary duplication
>
>
> I propose also that -O should imply -O2, not -O3.
>  -O2 seems to be heavily used in the wider world, -O3 not so much
>  For one thing, gcc itself defaults to building with -O2.
>
> I have it like this:
>
> if not defined("m3back_optimize")
>  m3back_optimize = "-O2"
> end
>
> if not defined("m3back_debug")
>
> m3back_debug = "-gstaus+"
>
> end
>
>
> and then
> if optimize options += m3back_optimize end
> if debug options += m3back_debug  end
>
>
>
>
> individual users/platforms can override, such as PA64_HPUX setting m3back_debug = "" (maybe later to something else)
> maybe we can shift to dwarf at some point too, that seems to be the favored format on most platforms
>
>
>  - Jay
>
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Sat, 8 May 2010 12:01:12 -0400
>> To: wagner at elegosoft.com
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Compile Options
>>
>>
>>
>> -O used to work in the old config files.
>> Did it get lost?
>>
>>
>> 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 8 May 2010, at 06:40, Olaf Wagner wrote:
>>
>> Quoting Jay K>:
>>
>> -O is the config files
>> It gets passed on to them and they may or may not pay attention.
>>
>> Turning off symbol generation not something I'm very sympathetic too.
>> I realize it cuts I/O, build time, resulting binary size (possibly load/runtime,
>> depending on the load behavior of symbols). Though on Windows
>> the symbols go into separate files, greatly reducing any negative affect.
>> On one hand, you don't want to inhibit debugging,
>>
>> Of course you may want to strip symbols for programs delivered to
>> customers.
>>
>> but on the other, we don't have a good debugger story anyway.
>>
>> m3gdb works well on certain platforms.
>>
>> Again, check the config files.
>>
>> -c I don't know. Is it important?
>>
>> The front end just includes some quake calls in the generated
>> m3make file for the options:
>>
>> % less AMD64_FREEBSD/m3make.args
>> set_config_options ()
>> readonly _all = TRUE % cm3 -build
>> m3_optimize (TRUE) <----
>> m3_debug (TRUE) <----
>> M3_KEEP_FILES = TRUE
>> m3_compile_only () <----
>> M3_MODE = "build"
>> include_dir ("../src")
>>
>> At least optimize and debug used to work some time ago; I'm not
>> sure about compile-only.
>>
>> Was something lost during the great config refactoring?
>> Can you please check that, Jay?
>>
>> I think we shold implement the CLI as documented. We _might_ discuss
>> the value-add of -c (I've never used it).
>>
>> We're probably missing regression tests for these simple command line
>> arguments, too.
>>
>> 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  Sun May  9 01:43:09 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 08 May 2010 16:43:09 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu> 
References: <20100508220958.8EA242474003@birch.elegosoft.com>,
	<62B45315-F33E-4586-BCCE-CE57F5E307EA@cs.purdue.edu>
	<COL101-W455DE8BD33138D220620E6E6F70@phx.gbl>,
	<C7985D61-0C4C-44B8-ACBE-2548725E3153@cs.purdue.edu>
	<COL101-W94565E47A143953025584E6F70@phx.gbl>
	<6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu>
Message-ID: <20100508234309.937D21A2095@async.async.caltech.edu>

I've been following the discussion at a distance and am trying to understand
what problem is being guarded against?

The possibility that users change the signal mask?  Signal mask is not
part of Modula-3.  I think a programmer who messes with the signal mask
shouldn't expect Modula-3 to restore it for him when it switches threads,
processes exceptions, etc.

If you want to provide hooks for it that would be nice but I think it's
strictly optional.

"Correctness" should (as always) mean correctness w.r.t. the Green Book,
which makes no mention at all of signals... It does mention FloatMode
however (page 75).

    Mika

Tony Hosking writes:
>
>--Apple-Mail-78-848772270
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/plain;
>	charset=us-ascii
>
>I think we can argue that a programmer should program around this using =
>TRY...FINALLY (i.e., even if they used FloatMode).
>
>So, I think we are safe with jmpbuf instead of sigjmpbuf.
>
>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 8 May 2010, at 18:56, Jay K wrote:
>
>>=20
>> Is "proper" saving/restoring as much as we can think of, or is it =
>fast, or is it matching Ada and C++, or .. ?
>> Ada and C++ (gnat and g++) have often/historically used =
>setjmp/longjmp.
>>   configure -enable-sjlj-exceptions
>> It might be interesting to see if they try to avoid the signal mask =
>versions when they use setjmp/longjmp.
>> Lately they use table-based unwinding on platforms that they can -- =
>which is to say, I *really* doubt
>> they save/restore the signal mask, but they might.
>>=20
>>=20
>>  - Jay
>>=20
>> ----------------------------------------
>>> Subject: Re: [M3commit] CVS Update: cm3
>>> From: hosking at cs.purdue.edu
>>> Date: Sat, 8 May 2010 18:51:18 -0400
>>> CC: jkrell at elego.de; m3commit at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>=20
>>>=20
>>>=20
>>> On 8 May 2010, at 18:38, Jay K wrote:
>>>=20
>>>> Or, understood, you really think we might throw around a signal mask =
>change?
>>>=20
>>> It's possible.
>>>=20
>>>> Realize also that sigsetjmp or setjmp, whichever we use, is called =
>incredibly often, and sigsetjmp is likely
>>>> much much slower. Also notice..this I'll have to check...have we =
>ever called sigsetjmp?
>>>> Well, no, I doubt it. But maybe setjmp vs. _setjmp.
>>>> Again though, this can be significantly slow.
>>>>=20
>>>>=20
>>>> Ultimately as well...see..I started this email without a firm =
>opinion, but now I'm "firming" toward the change I made.
>>>> Consider C++ exceptions. Consider libunwind. Consider the SPARC =
>stack walker (which I have to look at).
>>>> Do they save/restore signal masks? I doubt it. Maybe. We can look =
>into it. But I doubt it.
>>>=20
>>> We should confirm.
>>>=20
>>>> Raising an exception can indeed by slow. But entering a function =
>with finally (or destructors) should not be overly so.
>>>=20
>>> Ultimately, we should use proper stack unwinding wherever possible.
>>>=20
>>>>=20
>>>>=20
>>>> - Jay
>>>>=20
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Sat, 8 May 2010 18:28:36 -0400
>>>>> To: jkrell at elego.de
>>>>> CC: m3commit at elegosoft.com
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>=20
>>>>> Ah, now I remember. sigjmpbuf is important for unwinding on =
>exception to make sure that if we unwind through a frame where the =
>programmer changed the signal mask that we also restore the signal mask =
>of the caller. I think you also probably break things like FloatMode by =
>not restoring the signal mask properly.
>>>>>=20
>>>>> On 9 May 2010, at 00:09, Jay Krell wrote:
>>>>>=20
>>>>>> CVSROOT: /usr/cvs
>>>>>> Changes by: jkrell at birch. 10/05/09 00:09:58
>>>>>>=20
>>>>>> Modified files:
>>>>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3
>>>>>>=20
>>>>>> Log message:
>>>>>> add SPARC32_SOLARIS
>>>>>>=20
>>>>>> correct jmpbuf sizes for I386_SOLARIS, AMD64_SOLARIS
>>>>>> notice again that jmpbuf is much much smaller than sigjmpbuf,
>>>>>> and this is jmpbuf; specifically:
>>>>>> I386_SOLARIS jmpbuf 40 bytes with 4 align
>>>>>> AMD64_SOLARIS jmpbuf 64 bytes with 8 align
>>>>>> I386_SOLARIS sigjmpbuf 512 bytes with 4 align
>>>>>> AMD64_SOLARIS sigjmpbuf 1024 bytes with 8 align
>>>>>>=20
>>>>>> remove some level of heap allocation of calling conventions
>>>>>>=20
>>>>>> accept all calling conventions for all targets
>>>>>> Only NT386 has calling conventions, and it *highly* likely
>>>>>> the only target ever to have them, therefore the mechanism
>>>>>> does not need to be further generalized. (MIPS32 has two
>>>>>> ABIs, but those will probably be two targets)
>>>>>> This might let us save some unnecessary forking of *.i3 files.
>>>>>> The initialization here can be further streamlined.
>>>>>>=20
>>>>>> shrink SOLgnu/SOLsun from sigjmpbuf to jmpbuf
>>>>>> I'm not sure we use this though since we have a stack walker.
>>>>>> fix SPARC64_SOLARIS too to be smaller
>>>>>>=20
>>>>>> SPARC32_SOLARIS
>>>>>> jmpbuf size: 48
>>>>>> sigjmpbuf size: 76
>>>>>> alignment: 4 4
>>>>>>=20
>>>>>> SPARC64_SOLARIS
>>>>>> jmpbuf size: 96
>>>>>> sigjmpbuf size: 152
>>>>>> alignment: 8 8
>>>>>=20
>>>>=20
>>>=20
>> 		 	   		 =20
>
>
>--Apple-Mail-78-848772270
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/html;
>	charset=us-ascii
>
><html><head></head><body style=3D"word-wrap: break-word; =
>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I =
>think we can argue that a programmer should program around this using =
>TRY...FINALLY (i.e., even if they used =
>FloatMode).<div><br></div><div>So, I think we are safe with jmpbuf =
>instead of sigjmpbuf.<br><div><br><div>
><span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
>auto; text-indent: 0px; text-transform: none; white-space: normal; =
>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>-webkit-border-vertical-spacing: 0px; =
>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>auto; -webkit-text-stroke-width: 0; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>font-family: Helvetica; font-size: 12px; font-style: normal; =
>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>line-height: normal; -webkit-text-decorations-in-effect: none; =
>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><span =
>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>font-style: normal; font-variant: normal; font-weight: normal; =
>letter-spacing: normal; line-height: normal; =
>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>white-space: normal; widows: 2; word-spacing: 0px; "><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF"><font =
>class=3D"Apple-style-span" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Antony =
>Hosking</span></span></font></font><font class=3D"Apple-style-span" =
>face=3D"Gill Sans"><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"font-family: =
>'Gill Sans'; "><span class=3D"Apple-converted-space">&nbsp;</span>|<span =
>class=3D"Apple-converted-space">&nbsp;</span></span></span><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; "><span =
>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; =
>">Associate Professor</span></span><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; "><span class=3D"Apple-style-span" =
>style=3D"font-family: 'Gill Sans'; ">&nbsp;| Computer Science | Purdue =
>University</span></span></font></div><div><font class=3D"Apple-style-span"=
> face=3D"GillSans-Light"><span class=3D"Apple-style-span" =
>style=3D"font-family: GillSans-Light; ">305 N. University Street | West =
>Lafayette | IN 47907 | USA</span></font></div><div><font =
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Office</span></span></font><font =
>class=3D"Apple-style-span" face=3D"GillSans-Light"><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; =
>">&nbsp;+1 765 494 6001 |<span =
>class=3D"Apple-converted-space">&nbsp;</span></span></span></font><font =
>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans"><span =
>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>'Gill Sans'; "><span class=3D"Apple-style-span" style=3D"color: rgb(0, =
>0, 255); font-family: 'Gill Sans'; ">Mobile</span></span></font><font =
>class=3D"Apple-style-span" face=3D"GillSans-Light"><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; "><span =
>class=3D"Apple-converted-space">&nbsp;</span>+1 765 427 =
>5484</span></span></font></div><div><font class=3D"Apple-style-span" =
>face=3D"GillSans-Light"><br =
>class=3D"khtml-block-placeholder"></font></div></span></span></span></span=
>></span></span></span><br =
>class=3D"Apple-interchange-newline"></span></div></span></span><br =
>class=3D"Apple-interchange-newline">
></div>
><br><div><div>On 8 May 2010, at 18:56, Jay K wrote:</div><br =
>class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><br>Is =
>"proper" saving/restoring as much as we can think of, or is it fast, or =
>is it matching Ada and C++, or .. ?<br>Ada and C++ (gnat and g++) have =
>often/historically used setjmp/longjmp.<br>&nbsp; configure =
>-enable-sjlj-exceptions<br>It might be interesting to see if they try to =
>avoid the signal mask versions when they use setjmp/longjmp.<br>Lately =
>they use table-based unwinding on platforms that they can -- which is to =
>say, I *really* doubt<br>they save/restore the signal mask, but they =
>might.<br><br><br>&nbsp;- =
>Jay<br><br>----------------------------------------<br><blockquote =
>type=3D"cite">Subject: Re: [M3commit] CVS Update: =
>cm3<br></blockquote><blockquote type=3D"cite">From: <a =
>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu</a><br></block=
>quote><blockquote type=3D"cite">Date: Sat, 8 May 2010 18:51:18 =
>-0400<br></blockquote><blockquote type=3D"cite">CC: <a =
>href=3D"mailto:jkrell at elego.de">jkrell at elego.de</a>; <a =
>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com</a><br></blo=
>ckquote><blockquote type=3D"cite">To: <a =
>href=3D"mailto:jay.krell at cornell.edu">jay.krell at cornell.edu</a><br></block=
>quote><blockquote type=3D"cite"><br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">On 8 May 2010, =
>at 18:38, Jay K wrote:<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">Or, understood, you really think we might throw around a =
>signal mask change?<br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">It's =
>possible.<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">Realize also that sigsetjmp or setjmp, whichever we use, =
>is called incredibly often, and sigsetjmp is =
>likely<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">much much slower. Also notice..this I'll have to =
>check...have we ever called =
>sigsetjmp?<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Well, no, I doubt it. But maybe =
>setjmp vs. _setjmp.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Again though, this can be =
>significantly slow.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Ultimately as well...see..I =
>started this email without a firm opinion, but now I'm "firming" toward =
>the change I made.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Consider C++ exceptions. =
>Consider libunwind. Consider the SPARC stack walker (which I have to =
>look at).<br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Do they save/restore signal =
>masks? I doubt it. Maybe. We can look into it. But I doubt =
>it.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">We should =
>confirm.<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite">Raising an exception can indeed by slow. But entering a =
>function with finally (or destructors) should not be overly =
>so.<br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite">Ultimately, we =
>should use proper stack unwinding wherever =
>possible.<br></blockquote><blockquote =
>type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite">- =
>Jay<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite">----------------------------------------<br></blockquote></b=
>lockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite">From: <a =
>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu</a><br></block=
>quote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Date: Sat, 8 May 2010 18:28:36 =
>-0400<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To: <a =
>href=3D"mailto:jkrell at elego.de">jkrell at elego.de</a><br></blockquote></bloc=
>kquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">CC: <a =
>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com</a><br></blo=
>ckquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Subject: Re: [M3commit] CVS =
>Update: cm3<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Ah, =
>now I remember. sigjmpbuf is important for unwinding on exception to =
>make sure that if we unwind through a frame where the programmer changed =
>the signal mask that we also restore the signal mask of the caller. I =
>think you also probably break things like FloatMode by not restoring the =
>signal mask =
>properly.<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">On 9 =
>May 2010, at 00:09, Jay Krell =
>wrote:<br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">CVSROOT: =
>/usr/cvs<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Changes by: jkrell at birch. =
>10/05/09 =
>00:09:58<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Modified =
>files:<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">cm3/m3-sys/m3middle/src/: =
>Target.i3 =
>Target.m3<br></blockquote></blockquote></blockquote></blockquote><blockquo=
>te type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Log =
>message:<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">add =
>SPARC32_SOLARIS<br></blockquote></blockquote></blockquote></blockquote><bl=
>ockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">correct jmpbuf sizes for =
>I386_SOLARIS, =
>AMD64_SOLARIS<br></blockquote></blockquote></blockquote></blockquote><bloc=
>kquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">notice again that jmpbuf is much =
>much smaller than =
>sigjmpbuf,<br></blockquote></blockquote></blockquote></blockquote><blockqu=
>ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">and this is jmpbuf; =
>specifically:<br></blockquote></blockquote></blockquote></blockquote><bloc=
>kquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">I386_SOLARIS jmpbuf 40 bytes =
>with 4 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">AMD64_SOLARIS jmpbuf 64 bytes =
>with 8 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">I386_SOLARIS sigjmpbuf 512 bytes =
>with 4 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">AMD64_SOLARIS sigjmpbuf 1024 =
>bytes with 8 =
>align<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">remove some level of heap =
>allocation of calling =
>conventions<br></blockquote></blockquote></blockquote></blockquote><blockq=
>uote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">accept all calling conventions =
>for all =
>targets<br></blockquote></blockquote></blockquote></blockquote><blockquote=
> type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">Only NT386 has calling =
>conventions, and it *highly* =
>likely<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">the only target ever to have =
>them, therefore the =
>mechanism<br></blockquote></blockquote></blockquote></blockquote><blockquo=
>te type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">does not need to be further =
>generalized. (MIPS32 has =
>two<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">ABIs, but those will probably be =
>two =
>targets)<br></blockquote></blockquote></blockquote></blockquote><blockquot=
>e type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">This might let us save some =
>unnecessary forking of *.i3 =
>files.<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">The initialization here can be =
>further =
>streamlined.<br></blockquote></blockquote></blockquote></blockquote><block=
>quote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">shrink SOLgnu/SOLsun from =
>sigjmpbuf to =
>jmpbuf<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">I'm not sure we use this though =
>since we have a stack =
>walker.<br></blockquote></blockquote></blockquote></blockquote><blockquote=
> type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">fix SPARC64_SOLARIS too to be =
>smaller<br></blockquote></blockquote></blockquote></blockquote><blockquote=
> type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite">SPARC32_SOLARIS<br></blockquote></blockquote></blockquote></=
>blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote=
> type=3D"cite"><blockquote type=3D"cite">jmpbuf size: =
>48<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">sigjmpbuf size: =
>76<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">alignment: 4 =
>4<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
>ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite">SPARC64_SOLARIS<br></blockquote></blockquote></blockquote></=
>blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote=
> type=3D"cite"><blockquote type=3D"cite">jmpbuf size: =
>96<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">sigjmpbuf size: =
>152<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><blockquote type=3D"cite">alignment: 8 =
>8<br></blockquote></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
>type=3D"cite"><blockquote =
>type=3D"cite"><br></blockquote></blockquote><blockquote =
>type=3D"cite"><br></blockquote> <span class=3D"Apple-tab-span" =
>style=3D"white-space:pre">	</span><span class=3D"Apple-tab-span" =
>style=3D"white-space:pre">	</span> <span class=3D"Apple-tab-span" =
>style=3D"white-space:pre">	</span> &nbsp;&nbsp;<span =
>class=3D"Apple-tab-span" style=3D"white-space:pre">	</span><span =
>class=3D"Apple-tab-span" style=3D"white-space:pre">	</span> =
>&nbsp;<br></div></blockquote></div><br></div></div></body></html>=
>
>--Apple-Mail-78-848772270--


From jay.krell at cornell.edu  Sun May  9 01:49:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 23:49:13 +0000
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20100508234309.937D21A2095@async.async.caltech.edu>
References: <20100508220958.8EA242474003@birch.elegosoft.com>, ,
	<62B45315-F33E-4586-BCCE-CE57F5E307EA@cs.purdue.edu>,
	<COL101-W455DE8BD33138D220620E6E6F70@phx.gbl>, ,
	<C7985D61-0C4C-44B8-ACBE-2548725E3153@cs.purdue.edu>,
	<COL101-W94565E47A143953025584E6F70@phx.gbl>,
	<6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu>,
	<20100508234309.937D21A2095@async.async.caltech.edu>
Message-ID: <COL101-W487024C8B81D4B8120C348E6F70@phx.gbl>


It's not a closed system. Modula-3 can call C can call C++ can call Modula-3, etc., and they can call raise exceptions.
I'm not sure what the C exception story is on all platforms, but at least on Windows there is RaiseException.

Green book doesn't mention m3-libs/m3core/src/Unix, but it exists anyway.

?- Jay

----------------------------------------
> To: hosking at cs.purdue.edu
> Date: Sat, 8 May 2010 16:43:09 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> I've been following the discussion at a distance and am trying to understand
> what problem is being guarded against?
>
> The possibility that users change the signal mask? Signal mask is not
> part of Modula-3. I think a programmer who messes with the signal mask
> shouldn't expect Modula-3 to restore it for him when it switches threads,
> processes exceptions, etc.
>
> If you want to provide hooks for it that would be nice but I think it's
> strictly optional.
>
> "Correctness" should (as always) mean correctness w.r.t. the Green Book,
> which makes no mention at all of signals... It does mention FloatMode
> however (page 75).
>
> Mika
>
> Tony Hosking writes:
>>
>>--Apple-Mail-78-848772270
>>Content-Transfer-Encoding: quoted-printable
>>Content-Type: text/plain;
>> charset=us-ascii
>>
>>I think we can argue that a programmer should program around this using =
>>TRY...FINALLY (i.e., even if they used FloatMode).
>>
>>So, I think we are safe with jmpbuf instead of sigjmpbuf.
>>
>>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 8 May 2010, at 18:56, Jay K wrote:
>>
>>>=20
>>> Is "proper" saving/restoring as much as we can think of, or is it =
>>fast, or is it matching Ada and C++, or .. ?
>>> Ada and C++ (gnat and g++) have often/historically used =
>>setjmp/longjmp.
>>> configure -enable-sjlj-exceptions
>>> It might be interesting to see if they try to avoid the signal mask =
>>versions when they use setjmp/longjmp.
>>> Lately they use table-based unwinding on platforms that they can -- =
>>which is to say, I *really* doubt
>>> they save/restore the signal mask, but they might.
>>>=20
>>>=20
>>> - Jay
>>>=20
>>> ----------------------------------------
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sat, 8 May 2010 18:51:18 -0400
>>>> CC: jkrell at elego.de; m3commit at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>=20
>>>>=20
>>>>=20
>>>> On 8 May 2010, at 18:38, Jay K wrote:
>>>>=20
>>>>> Or, understood, you really think we might throw around a signal mask =
>>change?
>>>>=20
>>>> It's possible.
>>>>=20
>>>>> Realize also that sigsetjmp or setjmp, whichever we use, is called =
>>incredibly often, and sigsetjmp is likely
>>>>> much much slower. Also notice..this I'll have to check...have we =
>>ever called sigsetjmp?
>>>>> Well, no, I doubt it. But maybe setjmp vs. _setjmp.
>>>>> Again though, this can be significantly slow.
>>>>>=20
>>>>>=20
>>>>> Ultimately as well...see..I started this email without a firm =
>>opinion, but now I'm "firming" toward the change I made.
>>>>> Consider C++ exceptions. Consider libunwind. Consider the SPARC =
>>stack walker (which I have to look at).
>>>>> Do they save/restore signal masks? I doubt it. Maybe. We can look =
>>into it. But I doubt it.
>>>>=20
>>>> We should confirm.
>>>>=20
>>>>> Raising an exception can indeed by slow. But entering a function =
>>with finally (or destructors) should not be overly so.
>>>>=20
>>>> Ultimately, we should use proper stack unwinding wherever possible.
>>>>=20
>>>>>=20
>>>>>=20
>>>>> - Jay
>>>>>=20
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Sat, 8 May 2010 18:28:36 -0400
>>>>>> To: jkrell at elego.de
>>>>>> CC: m3commit at elegosoft.com
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>=20
>>>>>> Ah, now I remember. sigjmpbuf is important for unwinding on =
>>exception to make sure that if we unwind through a frame where the =
>>programmer changed the signal mask that we also restore the signal mask =
>>of the caller. I think you also probably break things like FloatMode by =
>>not restoring the signal mask properly.
>>>>>>=20
>>>>>> On 9 May 2010, at 00:09, Jay Krell wrote:
>>>>>>=20
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: jkrell at birch. 10/05/09 00:09:58
>>>>>>>=20
>>>>>>> Modified files:
>>>>>>> cm3/m3-sys/m3middle/src/: Target.i3 Target.m3
>>>>>>>=20
>>>>>>> Log message:
>>>>>>> add SPARC32_SOLARIS
>>>>>>>=20
>>>>>>> correct jmpbuf sizes for I386_SOLARIS, AMD64_SOLARIS
>>>>>>> notice again that jmpbuf is much much smaller than sigjmpbuf,
>>>>>>> and this is jmpbuf; specifically:
>>>>>>> I386_SOLARIS jmpbuf 40 bytes with 4 align
>>>>>>> AMD64_SOLARIS jmpbuf 64 bytes with 8 align
>>>>>>> I386_SOLARIS sigjmpbuf 512 bytes with 4 align
>>>>>>> AMD64_SOLARIS sigjmpbuf 1024 bytes with 8 align
>>>>>>>=20
>>>>>>> remove some level of heap allocation of calling conventions
>>>>>>>=20
>>>>>>> accept all calling conventions for all targets
>>>>>>> Only NT386 has calling conventions, and it *highly* likely
>>>>>>> the only target ever to have them, therefore the mechanism
>>>>>>> does not need to be further generalized. (MIPS32 has two
>>>>>>> ABIs, but those will probably be two targets)
>>>>>>> This might let us save some unnecessary forking of *.i3 files.
>>>>>>> The initialization here can be further streamlined.
>>>>>>>=20
>>>>>>> shrink SOLgnu/SOLsun from sigjmpbuf to jmpbuf
>>>>>>> I'm not sure we use this though since we have a stack walker.
>>>>>>> fix SPARC64_SOLARIS too to be smaller
>>>>>>>=20
>>>>>>> SPARC32_SOLARIS
>>>>>>> jmpbuf size: 48
>>>>>>> sigjmpbuf size: 76
>>>>>>> alignment: 4 4
>>>>>>>=20
>>>>>>> SPARC64_SOLARIS
>>>>>>> jmpbuf size: 96
>>>>>>> sigjmpbuf size: 152
>>>>>>> alignment: 8 8
>>>>>>=20
>>>>>=20
>>>>=20
>>> =20
>>
>>
>>--Apple-Mail-78-848772270
>>Content-Transfer-Encoding: quoted-printable
>>Content-Type: text/html;
>> charset=us-ascii
>>
>>>>-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I =
>>think we can argue that a programmer should program around this using =
>>TRY...FINALLY (i.e., even if they used =
>>FloatMode).
So, I think we are safe with jmpbuf =
>>instead of sigjmpbuf.


>>>>color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
>>auto; text-indent: 0px; text-transform: none; white-space: normal; =
>>widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
>>-webkit-border-vertical-spacing: 0px; =
>>-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
>>auto; -webkit-text-stroke-width: 0; ">>>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>>font-family: Helvetica; font-size: 12px; font-style: normal; =
>>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>>line-height: normal; -webkit-text-decorations-in-effect: none; =
>>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">>>style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
>>-webkit-line-break: after-white-space; ">>>style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
>>0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
>>font-family: Helvetica; font-size: 12px; font-style: normal; =
>>font-variant: normal; font-weight: normal; letter-spacing: normal; =
>>line-height: normal; -webkit-text-decorations-in-effect: none; =
>>text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
>>orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" style=3D"border-collapse: separate; =
>>-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
>>0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
>>font-style: normal; font-variant: normal; font-weight: normal; =
>>letter-spacing: normal; line-height: normal; =
>>-webkit-text-decorations-in-effect: none; text-indent: 0px; =
>>-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
>>white-space: normal; widows: 2; word-spacing: 0px; ">>>class=3D"Apple-style-span" color=3D"#0000FF">>>class=3D"Apple-style-span" face=3D"Gill Sans">>>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>>'Gill Sans'; ">>>0, 255); font-family: 'Gill Sans'; ">Antony =
>>Hosking>>face=3D"Gill Sans">>>'Gill Sans'; ">>>'Gill Sans'; ">?|>>class=3D"Apple-converted-space">?>>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; ">>>class=3D"Apple-style-span" style=3D"font-family: 'Gill Sans'; =
>>">Associate Professor>>style=3D"font-family: 'Gill Sans'; ">>>style=3D"font-family: 'Gill Sans'; ">?| Computer Science | Purdue =
>>University>> face=3D"GillSans-Light">>>style=3D"font-family: GillSans-Light; ">305 N. University Street | West =
>>Lafayette | IN 47907 | USA>>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans">>>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>>'Gill Sans'; ">>>0, 255); font-family: 'Gill Sans'; ">Office>>class=3D"Apple-style-span" face=3D"GillSans-Light">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; =
>>">?+1 765 494 6001 |>>class=3D"Apple-converted-space">?>>class=3D"Apple-style-span" color=3D"#0000FF" face=3D"Gill Sans">>>class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 255); font-family: =
>>'Gill Sans'; ">>>0, 255); font-family: 'Gill Sans'; ">Mobile>>class=3D"Apple-style-span" face=3D"GillSans-Light">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">>>class=3D"Apple-style-span" style=3D"font-family: GillSans-Light; ">>>class=3D"Apple-converted-space">?+1 765 427 =
>>5484>>face=3D"GillSans-Light">
>>class=3D"khtml-block-placeholder">
>>>
>>class=3D"Apple-interchange-newline">
>>class=3D"Apple-interchange-newline">
>>
>>
On 8 May 2010, at 18:56, Jay K wrote:
>>class=3D"Apple-interchange-newline">
Is =
>>"proper" saving/restoring as much as we can think of, or is it fast, or =
>>is it matching Ada and C++, or .. ?
Ada and C++ (gnat and g++) have =
>>often/historically used setjmp/longjmp.
? configure =
>>-enable-sjlj-exceptions
It might be interesting to see if they try to =
>>avoid the signal mask versions when they use setjmp/longjmp.
Lately =
>>they use table-based unwinding on platforms that they can -- which is to =
>>say, I *really* doubt
they save/restore the signal mask, but they =
>>might.


?- =
>>Jay

----------------------------------------
>>type=3D"cite">Subject: Re: [M3commit] CVS Update: =
>>cm3
From:>>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu

>>quote>Date: Sat, 8 May 2010 18:51:18 =
>>-0400
CC:>>href=3D"mailto:jkrell at elego.de">jkrell at elego.de;>>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com

>>ckquote>To:>>href=3D"mailto:jay.krell at cornell.edu">jay.krell at cornell.edu

>>quote>
>>type=3D"cite">
>>type=3D"cite">
On 8 May 2010, =
>>at 18:38, Jay K wrote:
>>type=3D"cite">
>>type=3D"cite">Or, understood, you really think we might throw around a =
>>signal mask change?
>>type=3D"cite">
It's =
>>possible.
>>type=3D"cite">
>>type=3D"cite">Realize also that sigsetjmp or setjmp, whichever we use, =
>>is called incredibly often, and sigsetjmp is =
>>likely
>>type=3D"cite">much much slower. Also notice..this I'll have to =
>>check...have we ever called =
>>sigsetjmp?
>>type=3D"cite">Well, no, I doubt it. But maybe =
>>setjmp vs. _setjmp.
>>type=3D"cite">Again though, this can be =
>>significantly slow.
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">Ultimately as well...see..I =
>>started this email without a firm opinion, but now I'm "firming" toward =
>>the change I made.
>>type=3D"cite">Consider C++ exceptions. =
>>Consider libunwind. Consider the SPARC stack walker (which I have to =
>>look at).
>>type=3D"cite">Do they save/restore signal =
>>masks? I doubt it. Maybe. We can look into it. But I doubt =
>>it.
>>type=3D"cite">
We should =
>>confirm.
>>type=3D"cite">
>>type=3D"cite">Raising an exception can indeed by slow. But entering a =
>>function with finally (or destructors) should not be overly =
>>so.
>>type=3D"cite">
Ultimately, we =
>>should use proper stack unwinding wherever =
>>possible.
>>type=3D"cite">
>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">- =
>>Jay
>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">----------------------------------------

>>lockquote>>>type=3D"cite">From:>>href=3D"mailto:hosking at cs.purdue.edu">hosking at cs.purdue.edu

>>quote>>>type=3D"cite">Date: Sat, 8 May 2010 18:28:36 =
>>-0400
>>type=3D"cite">To:>>href=3D"mailto:jkrell at elego.de">jkrell at elego.de

>>kquote>>>type=3D"cite">CC:>>href=3D"mailto:m3commit at elegosoft.com">m3commit at elegosoft.com

>>ckquote>>>type=3D"cite">Subject: Re: [M3commit] CVS =
>>Update: cm3
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">Ah, =
>>now I remember. sigjmpbuf is important for unwinding on exception to =
>>make sure that if we unwind through a frame where the programmer changed =
>>the signal mask that we also restore the signal mask of the caller. I =
>>think you also probably break things like FloatMode by not restoring the =
>>signal mask =
>>properly.
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">On 9 =
>>May 2010, at 00:09, Jay Krell =
>>wrote:
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">CVSROOT: =
>>/usr/cvs

>>e type=3D"cite">>>type=3D"cite">Changes by: jkrell at birch. =
>>10/05/09 =
>>00:09:58

>>e type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">Modified =
>>files:
>>type=3D"cite">>>type=3D"cite">cm3/m3-sys/m3middle/src/: =
>>Target.i3 =
>>Target.m3

>>te type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">Log =
>>message:

>>e type=3D"cite">>>type=3D"cite">add =
>>SPARC32_SOLARIS

>>ockquote type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">correct jmpbuf sizes for =
>>I386_SOLARIS, =
>>AMD64_SOLARIS

>>kquote type=3D"cite">>>type=3D"cite">notice again that jmpbuf is much =
>>much smaller than =
>>sigjmpbuf,

>>ote type=3D"cite">>>type=3D"cite">and this is jmpbuf; =
>>specifically:

>>kquote type=3D"cite">>>type=3D"cite">I386_SOLARIS jmpbuf 40 bytes =
>>with 4 =
>>align
>>type=3D"cite">>>type=3D"cite">AMD64_SOLARIS jmpbuf 64 bytes =
>>with 8 =
>>align
>>type=3D"cite">>>type=3D"cite">I386_SOLARIS sigjmpbuf 512 bytes =
>>with 4 =
>>align
>>type=3D"cite">>>type=3D"cite">AMD64_SOLARIS sigjmpbuf 1024 =
>>bytes with 8 =
>>align
>>type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">remove some level of heap =
>>allocation of calling =
>>conventions

>>uote type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">accept all calling conventions =
>>for all =
>>targets

>> type=3D"cite">>>type=3D"cite">Only NT386 has calling =
>>conventions, and it *highly* =
>>likely
>>type=3D"cite">>>type=3D"cite">the only target ever to have =
>>them, therefore the =
>>mechanism

>>te type=3D"cite">>>type=3D"cite">does not need to be further =
>>generalized. (MIPS32 has =
>>two
>>type=3D"cite">>>type=3D"cite">ABIs, but those will probably be =
>>two =
>>targets)

>>e type=3D"cite">>>type=3D"cite">This might let us save some =
>>unnecessary forking of *.i3 =
>>files.
>>type=3D"cite">>>type=3D"cite">The initialization here can be =
>>further =
>>streamlined.

>>quote type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">shrink SOLgnu/SOLsun from =
>>sigjmpbuf to =
>>jmpbuf
>>type=3D"cite">>>type=3D"cite">I'm not sure we use this though =
>>since we have a stack =
>>walker.

>> type=3D"cite">>>type=3D"cite">fix SPARC64_SOLARIS too to be =
>>smaller

>> type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">>>type=3D"cite">SPARC32_SOLARIS
>>blockquote>
>> type=3D"cite">jmpbuf size: =
>>48
>>type=3D"cite">>>type=3D"cite">sigjmpbuf size: =
>>76
>>type=3D"cite">>>type=3D"cite">alignment: 4 =
>>4
>>type=3D"cite">>>type=3D"cite">>>type=3D"cite">

>>ckquote type=3D"cite">>>type=3D"cite">>>type=3D"cite">SPARC64_SOLARIS
>>blockquote>
>> type=3D"cite">jmpbuf size: =
>>96
>>type=3D"cite">>>type=3D"cite">sigjmpbuf size: =
>>152
>>type=3D"cite">>>type=3D"cite">alignment: 8 =
>>8
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">>>type=3D"cite">
>>type=3D"cite">
>>style=3D"white-space:pre">>>style=3D"white-space:pre"> >>style=3D"white-space:pre">  ??>>class=3D"Apple-tab-span" style=3D"white-space:pre">>>class=3D"Apple-tab-span" style=3D"white-space:pre">  =
>>?

=
>>
>>--Apple-Mail-78-848772270--
 		 	   		  

From jay.krell at cornell.edu  Sun May  9 01:54:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 8 May 2010 23:54:49 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>,
	<COL101-W3400AD99D6E69DC7E8F466E6F70@phx.gbl>,
	<20100508124004.fnerkfmes8wc0wk0@mail.elegosoft.com>
Message-ID: <COL101-W2850411CE9F0D7659AA965E6F70@phx.gbl>


>> but on the other, we don't have a good debugger story anyway.
>
> m3gdb works well on certain platforms.


?I don't want to build m3gdb.
?It doesn't work on all platforms.
?gdb should suffice.
? Must parameters/locals really have gibberish names and can we really not
? represent the types in a manner that gdb understands?
?We need CodeView information on Windows.
At least I figured out that Debian 4.0 was part of the problem, fixed in Debian 5.0.
? (I didn't realize I was still running 4.0! I've upgraded since.)

?- Jay
 		 	   		  

From mika at async.async.caltech.edu  Sun May  9 01:55:53 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 08 May 2010 16:55:53 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W487024C8B81D4B8120C348E6F70@phx.gbl> 
References: <20100508220958.8EA242474003@birch.elegosoft.com>, ,
	<62B45315-F33E-4586-BCCE-CE57F5E307EA@cs.purdue.edu>,
	<COL101-W455DE8BD33138D220620E6E6F70@phx.gbl>, ,
	<C7985D61-0C4C-44B8-ACBE-2548725E3153@cs.purdue.edu>,
	<COL101-W94565E47A143953025584E6F70@phx.gbl>,
	<6B8563E5-FB3A-4FC6-B556-C150BA4F82D3@cs.purdue.edu>,
	<20100508234309.937D21A2095@async.async.caltech.edu>
	<COL101-W487024C8B81D4B8120C348E6F70@phx.gbl>
Message-ID: <20100508235553.70BB41A2097@async.async.caltech.edu>

Jay K writes:
>
>It's not a closed system. Modula-3 can call C can call C++ can call Modula-=
>3=2C etc.=2C and they can call raise exceptions.
>I'm not sure what the C exception story is on all platforms=2C but at least=
> on Windows there is RaiseException.
>
>Green book doesn't mention m3-libs/m3core/src/Unix=2C but it exists anyway.
>
>=A0- Jay

Well the fact that there is no specification means there's no definition
of what behavior is "correct."  I think it's up to the user of the 
primitives to ensure he's not breaking anything, if it's not defined 
in the Book.

Surely the way to deal with it is to make the user simply guarantee
that whatever C routines he calls will in fact conform with Modula-3's
parameter passing and exception behavior.  

So it would be nice to document how one goes about writing a C program
so that it conforms with (a particular implementation of) Modula-3's
conventions.  But changing the signal mask?  Maybe such a programmer
shouldn't be programming in Modula-3, not if his demands on M3 cause
things to slow down significantly for users who are writing their code
mostly in Modula-3.  (As far as I know there's no real reason to write
your code in C if you can use Modula-3, not sure about C++.)

    Mika


From rcolebur at SCIRES.COM  Sun May  9 03:14:53 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 8 May 2010 21:14:53 -0400
Subject: [M3devel] m3core broken on Usocket.c in HEAD
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C1895B4B@ATLEX02-SRV.SCIRES.LOCAL>

I am noticing that Usocket.c in m3-libs\m3core fails to compile on Windows.
This is from the HEAD branch.
Regards,
Randy

________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100508/971abbb4/attachment-0002.html>

From peter.mckinna at gmail.com  Sun May  9 13:51:05 2010
From: peter.mckinna at gmail.com (Peter McKinna)
Date: Sun, 9 May 2010 21:51:05 +1000
Subject: [M3devel] Compile Options
In-Reply-To: <C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>
	<C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>
Message-ID: <j2t3d9e5afc1005090451x1ffbc3a1x664ce53571d300e2@mail.gmail.com>

Sorry should have mentioned AMD_64 linux.  I was trying to check if the code
generator was screwing up and every time I made a slight change the stabs
were completely different in the 2 ms files from the same module. In fact
the generated code was so completely different for just 2 lines of M3 I
found it incomprehensible. I tried to turn off the debugging to reduce the
clutter. So then I played around with some of the other compile time
switches and found some problems. This is in version 5.8.4

Regards
Peter

On Sat, May 8, 2010 at 2:55 PM, Tony Hosking <hosking at cs.purdue.edu> wrote:

> What target platform?
>
> On 8 May 2010, at 00:22, Peter McKinna wrote:
>
> > Hey,
> >
> >   Using -c to disable library or program generation does not seem to
> work. Also how do you turn off debug symbol generation?
> > And the -O switch doesnt seem to optimise anything.
> >
> >   Is it just me or the documentation.
> >
> > Regards
> >
> > Peter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100509/7020fda3/attachment-0002.html>

From jay.krell at cornell.edu  Sun May  9 14:44:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 9 May 2010 12:44:26 +0000
Subject: [M3devel] Compile Options
In-Reply-To: <j2t3d9e5afc1005090451x1ffbc3a1x664ce53571d300e2@mail.gmail.com>
References: <v2o3d9e5afc1005072122vf3d18592y8e4ca0282cd5af35@mail.gmail.com>,
	<C71F53E6-689D-466B-98BE-7F548A5F6B07@cs.purdue.edu>,
	<j2t3d9e5afc1005090451x1ffbc3a1x664ce53571d300e2@mail.gmail.com>
Message-ID: <COL101-W178E2932A99B8781F0FE6CE6F80@phx.gbl>


aha, good reason to disable debugging.

I think this has been broken a very long time -- the usage says debugging is the default,
and that is true..and I see no way to disable it..

Either we need like -g0 or the default should be no symbols.
??

You can also hack the config files -- remove any -g(stabs)(+).
? An ok option for your immediate purposes, if not the right general solution for everyone.


I forgot to mention in my commit comment: I did go ahead with the m3back_debug, m3back_optimize switches.
It should be you just set m3back_debug = "" in the toplevel config (or maybe with -D on the command line?) no symbols.

Also more subtly I changed optimizing from -O3 to -O2 -Wuninitialized.
Maybe should leave that alone..as I almost never use it either way.


?- Jay

________________________________
> Date: Sun, 9 May 2010 21:51:05 +1000
> From: peter.mckinna at gmail.com
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compile Options
>
> Sorry should have mentioned AMD_64 linux. I was trying to check if the code generator was screwing up and every time I made a slight change the stabs were completely different in the 2 ms files from the same module. In fact the generated code was so completely different for just 2 lines of M3 I found it incomprehensible. I tried to turn off the debugging to reduce the clutter. So then I played around with some of the other compile time switches and found some problems. This is in version 5.8.4
>
>
> Regards
> Peter
>
> On Sat, May 8, 2010 at 2:55 PM, Tony Hosking> wrote:
>
> What target platform?
>
>
>
> On 8 May 2010, at 00:22, Peter McKinna wrote:
>
>
>
>> Hey,
>
>>
>
>> Using -c to disable library or program generation does not seem to work. Also how do you turn off debug symbol generation?
>
>> And the -O switch doesnt seem to optimise anything.
>
>>
>
>> Is it just me or the documentation.
>
>>
>
>> Regards
>
>>
>
>> Peter
>
>
>
>
 		 	   		  

From wagner at elegosoft.com  Mon May 10 10:26:41 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 10 May 2010 10:26:41 +0200
Subject: [M3devel] builds on release branch broken
Message-ID: <20100510102641.ab1etdvcgs4s0oos@mail.elegosoft.com>

I just noticed several build failures on the release branch.
One seems to be caused by this:

=== package m3-sys/m3middle ===
  +++ cm3 -build  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'  
-DCM3_LAST_CHANGED='2010-04-11'  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'  
-DCM3LASTCHANGED='2010-04-11' $RARGS  && cm3 -ship $RARGS  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'  
-DCM3_LAST_CHANGED='2010-04-11'  
-DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'  
-DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'  
-DCM3LASTCHANGED='2010-04-11'  +++
gcc: ../src/POSIX/CoffTime.c: No such file or directory
gcc: No input files specified
   compile_c => 1
C compiler failed compiling: ../src/POSIX/CoffTime.c
gcc: ../src/POSIX/CoffTime.c: No such file or directory
gcc: No input files specified
   compile_c => 1
C compiler failed compiling: ../src/POSIX/CoffTime.c
retry build after cleaning

See http://hudson.modula3.com:8080/job/cm3-build-AMD64_FREEBSD/104/, too.

One of these commits seems to be the culprit:

Changes

    1. move _DARWIN_FEATURE_64_ONLY_BIT_INODE earlier, so that it will work
       (This only affects ARM_DARWIN I believe, and maybe not even  
it.) (detail)
    2. copy from head so it compiles (detail)
    3. copy from head, so that release can be built by "upgrading" from head
       (head m3core has cut down/removed Utime for portability, and it
       was used here)) (detail)
    4. whitespace only (detail)

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  Mon May 10 10:38:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 10 May 2010 08:38:44 +0000
Subject: [M3devel] builds on release branch broken
In-Reply-To: <20100510102641.ab1etdvcgs4s0oos@mail.elegosoft.com>
References: <20100510102641.ab1etdvcgs4s0oos@mail.elegosoft.com>
Message-ID: <COL101-W7420AE3AB05362E9C432FE6F90@phx.gbl>


understood, I'll fix shortly

?- Jay


----------------------------------------
> Date: Mon, 10 May 2010 10:26:41 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: [M3devel] builds on release branch broken
>
> I just noticed several build failures on the release branch.
> One seems to be caused by this:
>
> === package m3-sys/m3middle ===
> +++ cm3 -build
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'
> -DCM3_LAST_CHANGED='2010-04-11'
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'
> -DCM3LASTCHANGED='2010-04-11' $RARGS && cm3 -ship $RARGS
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3_VERSION_TEXT='post-5.8.5' -DCM3_VERSION_NUMBER='050805'
> -DCM3_LAST_CHANGED='2010-04-11'
> -DROOT='/pub/users/hudson/workspace/cm3-build-FreeBSD4/cm3'
> -DCM3VERSION='post-5.8.5' -DCM3VERSIONNUM='050805'
> -DCM3LASTCHANGED='2010-04-11' +++
> gcc: ../src/POSIX/CoffTime.c: No such file or directory
> gcc: No input files specified
> compile_c => 1
> C compiler failed compiling: ../src/POSIX/CoffTime.c
> gcc: ../src/POSIX/CoffTime.c: No such file or directory
> gcc: No input files specified
> compile_c => 1
> C compiler failed compiling: ../src/POSIX/CoffTime.c
> retry build after cleaning
>
> See http://hudson.modula3.com:8080/job/cm3-build-AMD64_FREEBSD/104/, too.
>
> One of these commits seems to be the culprit:
>
> Changes
>
> 1. move _DARWIN_FEATURE_64_ONLY_BIT_INODE earlier, so that it will work
> (This only affects ARM_DARWIN I believe, and maybe not even
> it.) (detail)
> 2. copy from head so it compiles (detail)
> 3. copy from head, so that release can be built by "upgrading" from head
> (head m3core has cut down/removed Utime for portability, and it
> was used here)) (detail)
> 4. whitespace only (detail)
>
> 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  Mon May 10 11:37:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 10 May 2010 09:37:21 +0000
Subject: [M3devel] program vs. Program
Message-ID: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>


Despite the length of this email, I don't think this is a big deal..


With the "origin/runpath" changes from a while ago, "program" "doesn't work", unless build_standalone.
At least on most systems. That is, you can't run the binary from its shipped location, in pkg.


We should consider: 
?- make program imply build_standalone? 
?- never ship "program" -- not runable within the package store? 
?- drop in wrapper .sh files that set/append LD_LIBRARY_PATH? 
?- maybe the scheme I alluded to, which I'm pretty sure libtool implements sometimes, where you use full paths on the initial link, an then "ship/install" relink first, either with new full paths or with $ORIGIN.


An exception would be, like, how gcc uses libexec/cc1.
?If something in bin calls out to something in pkg, and either the file in pkg is build_standalone, or, well $ORIGIN sometimes
?is relative to the executable -- like on Mac OSX 10.4 with @executable_path, but this is probably too rare to consider.
And even if we have "private" executables in "pkg", build_standalone is still wasteful.


So we'd want to look through stuff like:


jbook2:cm3 jay$ grep ^program `find . | grep /m3makefile$` | grep -v examples | grep -v test
./caltech-parser/hack/src/m3makefile:program("dummy")
./doc/tutorial/ui/script/m3makefile:program ("script")
./m3-comm/tapi/src/m3makefile:program ("foo2")
./m3-db/db/demo/m3makefile:program("demo")
./m3-db/db/src/postgresql/demo/m3makefile:program("demo")
./m3-db/stable/example/src/m3makefile:program("example")
./m3-demo/sharedboard/boardclient/src/m3makefile:program ("boardclient")
./m3-demo/sharedboard/boardserver/src/m3makefile:program ("boardserver")
./m3-demo/sharedboard/calendar/src/m3makefile:program ("calendar")
./m3-libs/digraph/src/m3makefile:program(DiGraphTest)
./m3-libs/digraph/src/m3makefile:program(TopSortTest)
./m3-libs/synthesizer/example/chirp/src/m3makefile:program("chirp")
./m3-libs/synthesizer/example/echo/src/m3makefile:program("echo")
./m3-libs/synthesizer/example/entchen/src/m3makefile:program("entchen")
./m3-libs/synthesizer/example/filter/src/m3makefile:program("filter")
./m3-libs/synthesizer/example/inout/src/m3makefile:program("inout")
./m3-libs/synthesizer/example/oscillator/src/m3makefile:program("oscillator")
./m3-libs/synthesizer/example/plot/src/m3makefile:program("plot")
./m3-libs/synthesizer/example/rueckwaerts/src/m3makefile:program("rueckwaerts")
./m3-libs/synthesizer/example/sirene/src/m3makefile:program("sirene")
./m3-libs/synthesizer/example/stereo/src/m3makefile:program("stereo")
./m3-libs/synthesizer/example/stream/src/m3makefile:program("stream")
./m3-libs/wellfett/example/src/m3makefile:program("example")
./m3-pkgtools/pkgfprint/src/m3makefile:program("pkgfp")
./m3-pkgtools/pkgq/src/m3makefile:program("pkgq")
./m3-pkgtools/pkgsrv/src/m3makefile:program("packageserver")
./m3-pkgtools/pkgtool/src/m3makefile:program("packagetool")
./m3-sys/cm3/src/m3makefile:program ("cm3")
./m3-sys/cminstall/src/m3makefile:program ("cminstall")
./m3-sys/dll2lib/src/m3makefile:program ("dll2lib")
./m3-sys/libdump/src/m3makefile:program ("libdump")
./m3-sys/m3cgcat/src/m3makefile:program ("m3cgcat")
./m3-sys/m3cggen/src/m3makefile:program ("m3cggen")
./m3-sys/m3staloneback/src/m3makefile:program ("m3back")
./m3-tools/cmpfp/src/m3makefile:program ("cmpfp")
./m3-tools/cvsup/cvpasswd/src/m3makefile:program("cvpasswd")
./m3-tools/macapi/src/m3makefile:program("macapi")
./m3-ui/juno-2/juno-app/pkl-fonts/src/m3makefile:program??? ??? ("PklFonts")
./m3-ui/juno-2/juno-machine/linear/src/m3makefile:program("LinearTest")
./m3-ui/juno-2/juno-machine/nonlinear/src/m3makefile:program??? ??? ("NonLinearTest")
./m3-ui/juno-2/juno-machine/runtime/src/m3makefile:program??? ??? ("RuntimeTest")
./m3-ui/juno-2/juno-machine/solve/src/m3makefile:program??? ??? ("SolveTest")


At a quick glance, a lot can be ignored. Anything without quotes doesn't curently build.
m3-pkgtools doesn't currently build.
cm3 and cminstall are "special" -- and still, we shouldn't bother putting them in pkg.
m3back is never used; m3ccgen is standalone and rarely used
libdump I think is unused; dll2lib is unused.
This doesn't check if things are build_standalone, e.g. PklFonts.


?- Jay


 		 	   		  

From hosking at cs.purdue.edu  Mon May 10 15:42:12 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 10 May 2010 09:42:12 -0400
Subject: [M3devel] program vs. Program
In-Reply-To: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>
References: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>
Message-ID: <358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>

program is not supposed to ship anything, right?

Only Program should do that.

On 10 May 2010, at 05:37, Jay K wrote:

> 
> Despite the length of this email, I don't think this is a big deal..
> 
> 
> With the "origin/runpath" changes from a while ago, "program" "doesn't work", unless build_standalone.
> At least on most systems. That is, you can't run the binary from its shipped location, in pkg.
> 
> 
> We should consider: 
>  - make program imply build_standalone? 
>  - never ship "program" -- not runable within the package store  
>  - drop in wrapper .sh files that set/append LD_LIBRARY_PATH? 
>  - maybe the scheme I alluded to, which I'm pretty sure libtool implements sometimes, where you use full paths on the initial link, an then "ship/install" relink first, either with new full paths or with $ORIGIN.
> 
> 
> An exception would be, like, how gcc uses libexec/cc1.
>  If something in bin calls out to something in pkg, and either the file in pkg is build_standalone, or, well $ORIGIN sometimes
>  is relative to the executable -- like on Mac OSX 10.4 with @executable_path, but this is probably too rare to consider.
> And even if we have "private" executables in "pkg", build_standalone is still wasteful.
> 
> 
> So we'd want to look through stuff like:
> 
> 
> jbook2:cm3 jay$ grep ^program `find . | grep /m3makefile$` | grep -v examples | grep -v test
> ./caltech-parser/hack/src/m3makefile:program("dummy")
> ./doc/tutorial/ui/script/m3makefile:program ("script")
> ./m3-comm/tapi/src/m3makefile:program ("foo2")
> ./m3-db/db/demo/m3makefile:program("demo")
> ./m3-db/db/src/postgresql/demo/m3makefile:program("demo")
> ./m3-db/stable/example/src/m3makefile:program("example")
> ./m3-demo/sharedboard/boardclient/src/m3makefile:program ("boardclient")
> ./m3-demo/sharedboard/boardserver/src/m3makefile:program ("boardserver")
> ./m3-demo/sharedboard/calendar/src/m3makefile:program ("calendar")
> ./m3-libs/digraph/src/m3makefile:program(DiGraphTest)
> ./m3-libs/digraph/src/m3makefile:program(TopSortTest)
> ./m3-libs/synthesizer/example/chirp/src/m3makefile:program("chirp")
> ./m3-libs/synthesizer/example/echo/src/m3makefile:program("echo")
> ./m3-libs/synthesizer/example/entchen/src/m3makefile:program("entchen")
> ./m3-libs/synthesizer/example/filter/src/m3makefile:program("filter")
> ./m3-libs/synthesizer/example/inout/src/m3makefile:program("inout")
> ./m3-libs/synthesizer/example/oscillator/src/m3makefile:program("oscillator")
> ./m3-libs/synthesizer/example/plot/src/m3makefile:program("plot")
> ./m3-libs/synthesizer/example/rueckwaerts/src/m3makefile:program("rueckwaerts")
> ./m3-libs/synthesizer/example/sirene/src/m3makefile:program("sirene")
> ./m3-libs/synthesizer/example/stereo/src/m3makefile:program("stereo")
> ./m3-libs/synthesizer/example/stream/src/m3makefile:program("stream")
> ./m3-libs/wellfett/example/src/m3makefile:program("example")
> ./m3-pkgtools/pkgfprint/src/m3makefile:program("pkgfp")
> ./m3-pkgtools/pkgq/src/m3makefile:program("pkgq")
> ./m3-pkgtools/pkgsrv/src/m3makefile:program("packageserver")
> ./m3-pkgtools/pkgtool/src/m3makefile:program("packagetool")
> ./m3-sys/cm3/src/m3makefile:program ("cm3")
> ./m3-sys/cminstall/src/m3makefile:program ("cminstall")
> ./m3-sys/dll2lib/src/m3makefile:program ("dll2lib")
> ./m3-sys/libdump/src/m3makefile:program ("libdump")
> ./m3-sys/m3cgcat/src/m3makefile:program ("m3cgcat")
> ./m3-sys/m3cggen/src/m3makefile:program ("m3cggen")
> ./m3-sys/m3staloneback/src/m3makefile:program ("m3back")
> ./m3-tools/cmpfp/src/m3makefile:program ("cmpfp")
> ./m3-tools/cvsup/cvpasswd/src/m3makefile:program("cvpasswd")
> ./m3-tools/macapi/src/m3makefile:program("macapi")
> ./m3-ui/juno-2/juno-app/pkl-fonts/src/m3makefile:program        ("PklFonts")
> ./m3-ui/juno-2/juno-machine/linear/src/m3makefile:program("LinearTest")
> ./m3-ui/juno-2/juno-machine/nonlinear/src/m3makefile:program        ("NonLinearTest")
> ./m3-ui/juno-2/juno-machine/runtime/src/m3makefile:program        ("RuntimeTest")
> ./m3-ui/juno-2/juno-machine/solve/src/m3makefile:program        ("SolveTest")
> 
> 
> At a quick glance, a lot can be ignored. Anything without quotes doesn't curently build.
> m3-pkgtools doesn't currently build.
> cm3 and cminstall are "special" -- and still, we shouldn't bother putting them in pkg.
> m3back is never used; m3ccgen is standalone and rarely used
> libdump I think is unused; dll2lib is unused.
> This doesn't check if things are build_standalone, e.g. PklFonts.
> 
> 
>  - Jay
> 
> 
> 		 	   		  



From wagner at elegosoft.com  Mon May 10 17:40:15 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Mon, 10 May 2010 17:40:15 +0200
Subject: [M3devel] program vs. Program
In-Reply-To: <358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>
References: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>
	<358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>
Message-ID: <20100510174015.0s21r39i68ck80sc@mail.elegosoft.com>

Quoting Tony Hosking <hosking at cs.purdue.edu>:

> program is not supposed to ship anything, right?

program ships to the /pkg/TARGET directory, while
Program shipts to /bin.

> Only Program should do that.
>
> On 10 May 2010, at 05:37, Jay K wrote:
>
>> Despite the length of this email, I don't think this is a big deal..
>>
>> With the "origin/runpath" changes from a while ago, "program"   
>> "doesn't work", unless build_standalone.
>> At least on most systems. That is, you can't run the binary from   
>> its shipped location, in pkg.
>>
>> We should consider:
>>  - make program imply build_standalone?

Probably simplest solution, but not really what I would expect.

>>  - never ship "program" -- not runable within the package store

Would be a non-compatible change.

>>  - drop in wrapper .sh files that set/append LD_LIBRARY_PATH?

Strange.

>>  - maybe the scheme I alluded to, which I'm pretty sure libtool   
>> implements sometimes, where you use full paths on the initial link,  
>>  an then "ship/install" relink first, either with new full paths or  
>>  with $ORIGIN.

Why not use the correct paths via $ORIGIN? For program they are
of course different than for Program. Too difficult?

Not yet sure what we should do,

Olaf


>>
>>
>> An exception would be, like, how gcc uses libexec/cc1.
>>  If something in bin calls out to something in pkg, and either the   
>> file in pkg is build_standalone, or, well $ORIGIN sometimes
>>  is relative to the executable -- like on Mac OSX 10.4 with   
>> @executable_path, but this is probably too rare to consider.
>> And even if we have "private" executables in "pkg",   
>> build_standalone is still wasteful.
>>
>>
>> So we'd want to look through stuff like:
>>
>>
>> jbook2:cm3 jay$ grep ^program `find . | grep /m3makefile$` | grep   
>> -v examples | grep -v test
>> ./caltech-parser/hack/src/m3makefile:program("dummy")
>> ./doc/tutorial/ui/script/m3makefile:program ("script")
>> ./m3-comm/tapi/src/m3makefile:program ("foo2")
>> ./m3-db/db/demo/m3makefile:program("demo")
>> ./m3-db/db/src/postgresql/demo/m3makefile:program("demo")
>> ./m3-db/stable/example/src/m3makefile:program("example")
>> ./m3-demo/sharedboard/boardclient/src/m3makefile:program ("boardclient")
>> ./m3-demo/sharedboard/boardserver/src/m3makefile:program ("boardserver")
>> ./m3-demo/sharedboard/calendar/src/m3makefile:program ("calendar")
>> ./m3-libs/digraph/src/m3makefile:program(DiGraphTest)
>> ./m3-libs/digraph/src/m3makefile:program(TopSortTest)
>> ./m3-libs/synthesizer/example/chirp/src/m3makefile:program("chirp")
>> ./m3-libs/synthesizer/example/echo/src/m3makefile:program("echo")
>> ./m3-libs/synthesizer/example/entchen/src/m3makefile:program("entchen")
>> ./m3-libs/synthesizer/example/filter/src/m3makefile:program("filter")
>> ./m3-libs/synthesizer/example/inout/src/m3makefile:program("inout")
>> ./m3-libs/synthesizer/example/oscillator/src/m3makefile:program("oscillator")
>> ./m3-libs/synthesizer/example/plot/src/m3makefile:program("plot")
>> ./m3-libs/synthesizer/example/rueckwaerts/src/m3makefile:program("rueckwaerts")
>> ./m3-libs/synthesizer/example/sirene/src/m3makefile:program("sirene")
>> ./m3-libs/synthesizer/example/stereo/src/m3makefile:program("stereo")
>> ./m3-libs/synthesizer/example/stream/src/m3makefile:program("stream")
>> ./m3-libs/wellfett/example/src/m3makefile:program("example")
>> ./m3-pkgtools/pkgfprint/src/m3makefile:program("pkgfp")
>> ./m3-pkgtools/pkgq/src/m3makefile:program("pkgq")
>> ./m3-pkgtools/pkgsrv/src/m3makefile:program("packageserver")
>> ./m3-pkgtools/pkgtool/src/m3makefile:program("packagetool")
>> ./m3-sys/cm3/src/m3makefile:program ("cm3")
>> ./m3-sys/cminstall/src/m3makefile:program ("cminstall")
>> ./m3-sys/dll2lib/src/m3makefile:program ("dll2lib")
>> ./m3-sys/libdump/src/m3makefile:program ("libdump")
>> ./m3-sys/m3cgcat/src/m3makefile:program ("m3cgcat")
>> ./m3-sys/m3cggen/src/m3makefile:program ("m3cggen")
>> ./m3-sys/m3staloneback/src/m3makefile:program ("m3back")
>> ./m3-tools/cmpfp/src/m3makefile:program ("cmpfp")
>> ./m3-tools/cvsup/cvpasswd/src/m3makefile:program("cvpasswd")
>> ./m3-tools/macapi/src/m3makefile:program("macapi")
>> ./m3-ui/juno-2/juno-app/pkl-fonts/src/m3makefile:program        ("PklFonts")
>> ./m3-ui/juno-2/juno-machine/linear/src/m3makefile:program("LinearTest")
>> ./m3-ui/juno-2/juno-machine/nonlinear/src/m3makefile:program         
>>  ("NonLinearTest")
>> ./m3-ui/juno-2/juno-machine/runtime/src/m3makefile:program          
>> ("RuntimeTest")
>> ./m3-ui/juno-2/juno-machine/solve/src/m3makefile:program          
>> ("SolveTest")
>>
>>
>> At a quick glance, a lot can be ignored. Anything without quotes   
>> doesn't curently build.
>> m3-pkgtools doesn't currently build.
>> cm3 and cminstall are "special" -- and still, we shouldn't bother   
>> putting them in pkg.
>> m3back is never used; m3ccgen is standalone and rarely used
>> libdump I think is unused; dll2lib is unused.
>> This doesn't check if things are build_standalone, e.g. PklFonts.
>>
>>
>>  - Jay
>>
>>
>>
>
>



-- 
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 rcolebur at SCIRES.COM  Mon May 10 21:19:39 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 10 May 2010 15:19:39 -0400
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <20100509063527.854BC2474003@birch.elegosoft.com>
References: <20100509063527.854BC2474003@birch.elegosoft.com>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C1895CB6@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

I agree with some of your sentiments about the ugliness of the POSIX GUI, e.g. C & G buttons for close and grow, but I again want to point out that the "Win32" GUI is not ideal either.

Please recall that the changes made in the Win32 side were to make the Trestle/FormsVBT GUI appear more like Windows NT GUI at the time, but these are only approximations and it is not identical.  Plus, the Windows GUI continues to evolve, so the look and feel is now even further apart from the Windows Aero interface, than in 1995 when my company paid CMass to make the Win32 NT mods.  I haven't used X-Windows in a while, so not sure how far apart Trestle on X is from just X.

The other aspect that needs to be considered is that if the look/feel of the GUI changes, someone needs to update all the Trestle/FormsVBT documentation to match.  This may also create a cascade of documentation edits for any user programs/systems built and documented using the prior look and feel.

Note that the operation of scroll bars as documented under Trestle/FormsVBT are radically different from Microsoft Windows.  The current Win32 scroll bar implementation is closer to MS Windows, but it is still different, and it is not documented in Trestle/FormsVBT.  (I have a write-up on this I can provide.)

Depending on the needs/desires of the M3 community, there may be a need to maintain some runtime switch or compile time option to switch between the old style look and feel and any new style that is implemented.

Perhaps we should have a discussion in the m3devel forum to see how folks want to proceed before making any radical changes in the GUI look and feel.

Regards,
Randy

-----Original Message-----
From: Jay Krell [mailto:jkrell at elego.de]
Sent: Sunday, May 09, 2010 4:35 AM
To: m3commit at elegosoft.com
Subject: [M3commit] CVS Update: cm3

CVSROOT:        /usr/cvs
Changes by:     jkrell at birch.   10/05/09 08:35:27

Modified files:
        cm3/m3-ui/vbtkit/src/lego/: ZChassisVBT.m3 m3makefile
        cm3/m3-ui/vbtkit/src/lego/POSIX/: m3makefile
        cm3/m3-ui/vbtkit/src/lego/WIN32/: m3makefile
Removed files:
        cm3/m3-ui/vbtkit/src/lego/POSIX/: ZChassisVBT.m3
        cm3/m3-ui/vbtkit/src/lego/WIN32/: ZChassisVBT.m3

Log message:
        unfork ZChassisVBT.m3

        instead of copying 140 lines and changing a few, when
        both variations are portable, you can test
        Compiler.ThisOS = Compiler.OS.POSIX or Compiler.OS.WIN32
        and just have both variations.

        Alternately, make a /smaller/ interface and /smaller/ implementation
        that just contains the changed functions/lines

        The larger ScrollerVBTClass.m3 file received more churn so
        merging might not be viable/worthwhile.

        Besides, the Posix gui is terrible here, G for grow, C for close,
        we should probably just use the Win32 gui everywhere.


CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s).  This email may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.


From jay.krell at cornell.edu  Tue May 11 00:17:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 10 May 2010 22:17:05 +0000
Subject: [M3devel] program vs. Program
In-Reply-To: <20100510174015.0s21r39i68ck80sc@mail.elegosoft.com>
References: <COL101-W638177FE6CF479B83E4D43E6F90@phx.gbl>,
	<358DC30C-D242-406E-99FF-2F4B9E10AE00@cs.purdue.edu>,
	<20100510174015.0s21r39i68ck80sc@mail.elegosoft.com>
Message-ID: <COL101-W16DE2F184010AA8A1AFF44E6F90@phx.gbl>


>>> - never ship "program" -- not runable within the package store
>
> Would be a non-compatible change.
 
 
It's already non-compatible imho, except if LD_LIBRARY_PATH is used.
 

>>> - drop in wrapper .sh files that set/append LD_LIBRARY_PATH?
>
> Strange.
 
 
I believe this is a practise in the wider world, though not
very common or considered very good.
 
Actually some things I read say LD_LIBRARY_PATH is meant for
running stuff before install. Just don't abuse it and
use it after install. (it is the old link below though,
I should read more)
 

> Why not use the correct paths via $ORIGIN? For program they are
> of course different than for Program. Too difficult?
 
 
Ah, like ../../lib? To go our of pkg/target and over to lib?
Yeah, that is possible.
I had that in, but such "far up" relative paths worry me.
If the program is moved around to a shallower structure
it could accidentally reach into unrelated stuff.
 
 
It is mitigated by using:
  $ORIGIN:$ORIGIN/../lib:$ORIGIN/../../lib
 
 
so at least you find closer stuff first.
Maybe we can put just the last element in for program.
 
 
> http://xahlee.org/UnixResource_dir/_/ldpath.html
 
 
This is an old link, mostly predates $ORIGIN,
but does bring up the possibility of
linking or editing paths at install time.
 
 
Controversial suggestion: use autoconf/libtool.
It probably handles this stuff already.
 
 
 - Jay
  		 	   		  

From wagner at elegosoft.com  Wed May 12 08:51:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 12 May 2010 08:51:24 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>,
	<20100511090214.5bsr2f24o4oscg88@mail.elegosof, t, .com>, <F6
	43890B-0 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>
Message-ID: <20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>

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

>> It's nothing like just shifting the jobs from Jay's machine to opencsw.
>> I've already made half a dozen changes for a simple compile job.
>
>
> Hm. Maybe I should try installing Solaris 2.9 on my machine? Or a   
> separate machine first?
> I would like to offload to Dago if possible.

I understand that.

I can now check out with CVS from the command line, both via the
pserver proxy and a forwarded port via ssh, but still no luck with
Hudson itself. The failure message stays the same
(see http://hudson.modula3.com:8080/view/SOLsun/job/dummy/7/console).

Ideas what's going on are welcome.

But it's not just CVS. The regression test scripts check for
explicit ssh reachability of birch.elegosoft.com; we need scp
or rsync to upload archives, and wget or curl to download.
I'm sure the list will get even longer if we inspect the existing
jobs.

> I had tried to install Solaris 2.8 and/or 2.9 at some point but hit   
> some difficulty.
> 2.10 I've now installed multiple times, it is fairly easy.
>
> So..remember..I don't have any fixed IP addresses at all.
> I use free dynamic DNS and port forwarding.
>   Stuff I didn't know about but Olaf pointed me toward and I'm   
> pleased with it. :)
> Is that viable here?
>   You wouldn't need dynamic DNS, just port forwarding. As I understand.
> Like, port 222 on login goes to 22 on current9s, stuff like that.

I doubt that opencsw will change their setup for m3.

I'm sure we can work around every little or big problem that comes
up, but I simply haven't got the time for it.

I'd be happy if anybody else tries to port all the SOLsun jobs
from http://hudson.modula3.com:8080/view/SOLsun/
(copy to another name and then adapt) to run on
http://hudson.modula3.com:8080/computer/opencsw_current9s/.

My simple test job currently is in
http://hudson.modula3.com:8080/view/SOLsun/job/dummy/

If nobody else volunteers, I'll try to work on it now and then, but
cannot promise any deadline.

Thanks for all your support,

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 May 12 09:43:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 12 May 2010 07:43:35 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4oscg88@mail.el egosof,
	t, .com>, <F6,43890B-0
	0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>
Message-ID: <COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>


> test scripts check for explicit ssh reachability of birch.elegosoft.com
 
 
I put that in.
I found the stuff too hard to use and would try to make it easier as I figured it out.
 
 
 
Well.. for now let's just leave Hudson on my machine asis.
  Maybe Tony can provide a machine?
 
 
 
So..a general dilemna is how to give Dago something for him giving us something.
And how much is enough on either side?
Don't want to take and not give back, or whatnot.
 
 
 
I386_SOLARIS, AMD64_SOLARIS are now in good shape.
See http://www.modula3.com/cm3/uploaded-archives/index.html.
 
 
 
System builds itself.
  The whole thing on x86/2.10. Up to opengl on x86/2.9.
    I think I'll just do an existance check on 2.9 and stuff built there will just omit it.
 
  I haven't tested the X apps yet.
 
  I haven't tried Sparc32/64 yet on 2.8/2.9, but they could very well work ok.
     2.8 would have a problem with user threads, but I know how to fix it.
     (Dago is ok dropping 2.8 anyway, and user threads also don't really matter).
 
 
How much value is there to an occasional manual build, vs. better automation?
  With or without running the tests?
  Like, not hudson?
 
 
At some point I'll probably setup Solaris/x86.
  I already have, multiple times, just haven't configured it to my liking and kept it up and running.
  But I'd like to offload some power/heat/environmental-responsibility maybe.
  Maybe trade for other OSes. :)
  Also distribute the responsibility anyway. You don't want it all depending on my network connectivity, even if it was good. :)
 
 
I may have another option for Solaris. I'll check.
 
 
I can think of somewhat rude suggestions, like:
   Commit access shall be limited unless commiter provides Hudson resources. :)
   Of any sort or non-zero quantity -- don't make things too hard.
   Heck -- surely Linux/x86 is among the easiest for anyone to take. :)
   Then again, I'm not a manager, maybe I shouldn't try to think of ways to motivate people. :)
 
 
Also maybe login is usable at least for Solaris 2.10 sparc stuff?
Or is that an abuse?
 
 
 
Thanks,
 - Jay


----------------------------------------
> Date: Wed, 12 May 2010 08:51:24 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com; trygvis at opencsw.org; dam at baltic-online.de
> Subject: Re: [M3devel] OpenCSW build farm access
>
> Quoting Jay K :
>
>>> It's nothing like just shifting the jobs from Jay's machine to opencsw.
>>> I've already made half a dozen changes for a simple compile job.
>>
>>
>> Hm. Maybe I should try installing Solaris 2.9 on my machine? Or a
>> separate machine first?
>> I would like to offload to Dago if possible.
>
> I understand that.
>
> I can now check out with CVS from the command line, both via the
> pserver proxy and a forwarded port via ssh, but still no luck with
> Hudson itself. The failure message stays the same
> (see http://hudson.modula3.com:8080/view/SOLsun/job/dummy/7/console).
>
> Ideas what's going on are welcome.
>
> But it's not just CVS. The regression test scripts check for
> explicit ssh reachability of birch.elegosoft.com; we need scp
> or rsync to upload archives, and wget or curl to download.
> I'm sure the list will get even longer if we inspect the existing
> jobs.
>
>> I had tried to install Solaris 2.8 and/or 2.9 at some point but hit
>> some difficulty.
>> 2.10 I've now installed multiple times, it is fairly easy.
>>
>> So..remember..I don't have any fixed IP addresses at all.
>> I use free dynamic DNS and port forwarding.
>> Stuff I didn't know about but Olaf pointed me toward and I'm
>> pleased with it. :)
>> Is that viable here?
>> You wouldn't need dynamic DNS, just port forwarding. As I understand.
>> Like, port 222 on login goes to 22 on current9s, stuff like that.
>
> I doubt that opencsw will change their setup for m3.
>
> I'm sure we can work around every little or big problem that comes
> up, but I simply haven't got the time for it.
>
> I'd be happy if anybody else tries to port all the SOLsun jobs
> from http://hudson.modula3.com:8080/view/SOLsun/
> (copy to another name and then adapt) to run on
> http://hudson.modula3.com:8080/computer/opencsw_current9s/.
>
> My simple test job currently is in
> http://hudson.modula3.com:8080/view/SOLsun/job/dummy/
>
> If nobody else volunteers, I'll try to work on it now and then, but
> cannot promise any deadline.
>
> Thanks for all your support,
>
> 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 May 12 11:39:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 12 May 2010 09:39:22 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof
	, t, .com>, <F6,43890B-0
	0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
Message-ID: <COL101-W266A3DC1739A617839710BE6FB0@phx.gbl>


Just to clarify: "leave the stuff on my machine for now" is more like
"I'm not pulling the plug, take your time with Dago"
and less like "give up on Dago".

I think the Hudson init script written in Groovy be the place
to fix $PATH, to find cvs.
Give me a bit..

?> another source for Solaris cycles

Like, someone who
?- has an easier network topology
?- no Solaris 2.9 desire/agenda, who we therefore won't disappoint
??? if we don't get 2.9 working

so we don't "steal" from Dago.
(Yes, I realize I'm being wishy-washy here..)

I agree though if you already have people using Hudson...

Give me a bit on the path/cvs thing.

And I have multiple options for x86 2.9 OpenGL.

?- Jay

----------------------------------------
> CC: wagner at elegosoft.com; m3devel at elegosoft.com; trygvis at opencsw.org
> From: dam at baltic-online.de
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] OpenCSW build farm access
> Date: Wed, 12 May 2010 11:05:37 +0200
>
> Hi,
>
> Am 12.05.2010 um 09:43 schrieb Jay K:
>> Well.. for now let's just leave Hudson on my machine asis.
>> Maybe Tony can provide a machine?
>
> I'm pretty sure we can work this out. Other projects are using
> the farm also with Hudson, so it should be quite possible in the
> current configuration.
>
>> So..a general dilemna is how to give Dago something for him giving
>> us something.
>> And how much is enough on either side?
>> Don't want to take and not give back, or whatnot.
>
> Just provide cvsup for Solaris 9 sparc/x86 and I am happy :-)
> Additionally,
> a goal of providing the buildfarm is to aid upstream projects in
> ensuring
> Solaris compatibility. As you obviously do that it is perfectly ok.
>
>> I386_SOLARIS, AMD64_SOLARIS are now in good shape.
>> See http://www.modula3.com/cm3/uploaded-archives/index.html.
>
> Cool.
>
>> System builds itself.
>> The whole thing on x86/2.10. Up to opengl on x86/2.9.
>> I think I'll just do an existance check on 2.9 and stuff built
>> there will just omit it.
>>
>> I haven't tested the X apps yet.
>>
>> I haven't tried Sparc32/64 yet on 2.8/2.9, but they could very well
>> work ok.
>> 2.8 would have a problem with user threads, but I know how to
>> fix it.
>> (Dago is ok dropping 2.8 anyway, and user threads also don't
>> really matter).
>
> Yes.
>
>> How much value is there to an occasional manual build, vs. better
>> automation?
>> With or without running the tests?
>> Like, not hudson?
>>
>> At some point I'll probably setup Solaris/x86.
>> I already have, multiple times, just haven't configured it to my
>> liking and kept it up and running.
>> But I'd like to offload some power/heat/environmental-
>> responsibility maybe.
>> Maybe trade for other OSes. :)
>> Also distribute the responsibility anyway. You don't want it all
>> depending on my network connectivity, even if it was good. :)
>>
>> I may have another option for Solaris. I'll check.
>
> I do feel offended ;-)
>
>> I can think of somewhat rude suggestions, like:
>> Commit access shall be limited unless commiter provides Hudson
>> resources. :)
>> Of any sort or non-zero quantity -- don't make things too hard.
>> Heck -- surely Linux/x86 is among the easiest for anyone to take. :)
>> Then again, I'm not a manager, maybe I shouldn't try to think of
>> ways to motivate people. :)
>>
>> Also maybe login is usable at least for Solaris 2.10 sparc stuff?
>> Or is that an abuse?
>
> It is not abuse, but there is no compiler there.
>
>
> Best regards
>
> -- Dago
>
 		 	   		  

From jay.krell at cornell.edu  Wed May 12 14:29:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 12 May 2010 12:29:28 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof ,, t, .com>,
	<F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
Message-ID: <COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>


Olaf, I have some leads:


1)

http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds#Distributedbuilds-Example%3AConfigurationonUnix

# /var/hudson/bin/launch-slave is a shell script that Hudson uses to execute jobs remotely. This shell script sets up PATH and a few other things before launching slave.jar. Below is a very simple example script.

#!/bin/bash

JAVA_HOME=/opt/SUN/jdk1.6.0_04
PATH=$PATH:$JAVA_HOME/bin
export PATH
java -jar /var/hudson/bin/slave.jar

On master or slave or ??

2)
You can modify $PATH across all nodes:
http://www.modula3.com:8080/configure
Global Properties: Environment variables
This is yucky but appears easy and would work.

3)
You can specify CVS executable there.
Maybe ~/cvs or $HOME/cvs ??????
Which we'd setup appropriately.


4)
Hudson initialization script.
http://wiki.hudson-ci.org/display/HUDSON/Post-initialization+script
$HUDSON_HOME/init.groovy
I'm not sure this runs on slave or master.
I'd want to remove :/opt/csw/bin:, /opt/csw/bin:
from start, :/opt/csw/bin from end, and then insert /opt/csw/bin
somewhere, like start. That's too much Groovy for me to write,
and get working within Hudson..there is System.getenv, but
I don't see how to set the variables.


5)
You can set "tool locations".
I can't find elaboration on what that means.
Maybe
tool=cvs
location=/opt/csw/bin/cvs
?

6)
There is some mention of "PATH+".
I tried that. Didn't work.

7)
http://hudson.361315.n4.nabble.com/Slave-environment-and-Java-path-issues-td383751.html#a383752

Thanks.? You correct that I didn't understand the difference when using a non-interactive shell.
In the end I solved the problem by putting together a simple launch-slave script which sets the environment I need:

#!/bin/bash

export JAVA_HOME=/usr/lib/java 
...


8)
http://hudson.361315.n4.nabble.com/slave-s-PATH-change-not-picked-up-td1558100.html#a1559051

You were right.? The ssh itself did not load the correct PATH (I
couldn't see it via putty).? It turns out ssh does not read
/etc/profile, but it does read user's .bashrc.? Go figure...


Maybe I'll fiddle with the Hudson keys or my old key and poke around more...


?- Jay 		 	   		  

From wagner at elegosoft.com  Wed May 12 16:09:37 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 12 May 2010 16:09:37 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof ,, t, .com>,
	<F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
Message-ID: <20100512160937.5kq1fothc44c4sck@mail.elegosoft.com>

Hi Jay,

thanks for your suggestions.

I'll try to get it working tomorrow. One of them should do :-)

Olaf

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

>
> Olaf, I have some leads:
>
>
> 1)
>
> http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds#Distributedbuilds-Example%3AConfigurationonUnix
>
> # /var/hudson/bin/launch-slave is a shell script that Hudson uses to  
>  execute jobs remotely. This shell script sets up PATH and a few   
> other things before launching slave.jar. Below is a very simple   
> example script.
>
> #!/bin/bash
>
> JAVA_HOME=/opt/SUN/jdk1.6.0_04
> PATH=$PATH:$JAVA_HOME/bin
> export PATH
> java -jar /var/hudson/bin/slave.jar
>
> On master or slave or ??
>
> 2)
> You can modify $PATH across all nodes:
> http://www.modula3.com:8080/configure
> Global Properties: Environment variables
> This is yucky but appears easy and would work.
>
> 3)
> You can specify CVS executable there.
> Maybe ~/cvs or $HOME/cvs ??????
> Which we'd setup appropriately.
>
>
> 4)
> Hudson initialization script.
> http://wiki.hudson-ci.org/display/HUDSON/Post-initialization+script
> $HUDSON_HOME/init.groovy
> I'm not sure this runs on slave or master.
> I'd want to remove :/opt/csw/bin:, /opt/csw/bin:
> from start, :/opt/csw/bin from end, and then insert /opt/csw/bin
> somewhere, like start. That's too much Groovy for me to write,
> and get working within Hudson..there is System.getenv, but
> I don't see how to set the variables.
>
>
> 5)
> You can set "tool locations".
> I can't find elaboration on what that means.
> Maybe
> tool=cvs
> location=/opt/csw/bin/cvs
> ?
>
> 6)
> There is some mention of "PATH+".
> I tried that. Didn't work.
>
> 7)
> http://hudson.361315.n4.nabble.com/Slave-environment-and-Java-path-issues-td383751.html#a383752
>
> Thanks.? You correct that I didn't understand the difference when   
> using a non-interactive shell.
> In the end I solved the problem by putting together a simple   
> launch-slave script which sets the environment I need:
>
> #!/bin/bash
>
> export JAVA_HOME=/usr/lib/java
> ...
>
>
> 8)
> http://hudson.361315.n4.nabble.com/slave-s-PATH-change-not-picked-up-td1558100.html#a1559051
>
> You were right.? The ssh itself did not load the correct PATH (I
> couldn't see it via putty).? It turns out ssh does not read
> /etc/profile, but it does read user's .bashrc.? Go figure...
>
>
> Maybe I'll fiddle with the Hudson keys or my old key and poke around more...
>
>
> ?- Jay



-- 
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  Thu May 13 16:05:21 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 13 May 2010 16:05:21 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os!, cg88@mail. elegosof ,, t, .com>,
	<F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>
Message-ID: <20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>

I finally managed to get CVS working.

I postponed current9s and set up some jobs on current10s, as that
should be equivalent to your machine, Jay.

However, compilation of the cm3cg1 backed fails:

http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console

Can you have a look?

TIA,

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 May 14 00:12:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 13 May 2010 22:12:31 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, !, cg88@mail .,elegos of ,, t,
	.com>, , <F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
Message-ID: <COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>


This will be easy. Several options.
 
 - Look at 4.5.0 and how they fixed it to compile with Sun cc.
   Since they probably did, compiling gcc with Sun cc is something people are interested/willing to do.
 
 - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
 
 - Maybe just change your $PATH, but I'd prefer previous.
 
Later.
 
 - Jay


----------------------------------------
> Date: Thu, 13 May 2010 16:05:21 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
> Subject: RE: [M3devel] OpenCSW build farm access
>
> I finally managed to get CVS working.
>
> I postponed current9s and set up some jobs on current10s, as that
> should be equivalent to your machine, Jay.
>
> However, compilation of the cm3cg1 backed fails:
>
> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>
> Can you have a look?
>
> TIA,
>
> 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  Fri May 14 00:49:24 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 14 May 2010 00:49:24 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, !, cg88@mail .,elegos of ,, t,
	.com>, , <F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
Message-ID: <20100514004924.je7gtb922o40wck8@mail.elegosoft.com>

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

> This will be easy. Several options.
>
>  - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>    Since they probably did, compiling gcc with Sun cc is something   
> people are interested/willing to do.
>
>  - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>
>  - Maybe just change your $PATH, but I'd prefer previous.
>
> Later.

In the meantime, I put gcc in the path, which is a bit like cheating...
Now the first job has succeeded :-)
cm3-build still has other problems. I hope to have one set of working
jobs on current10s by tomorrow evening.

Olaf

>  - Jay
>
>
> ----------------------------------------
>> Date: Thu, 13 May 2010 16:05:21 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>> Subject: RE: [M3devel] OpenCSW build farm access
>>
>> I finally managed to get CVS working.
>>
>> I postponed current9s and set up some jobs on current10s, as that
>> should be equivalent to your machine, Jay.
>>
>> However, compilation of the cm3cg1 backed fails:
>>
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>
>> Can you have a look?
>>
>> TIA,
>>
>> 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
>>



-- 
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  Fri May 14 07:52:45 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 14 May 2010 07:52:45 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, !, cg88@mail .,elegos of ,, t,
	.com>, , <F6, 43890B-0, 0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>
Message-ID: <20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>

Hi again,

with some tweaking, some `standard' Hudson jobs have now complete
for cm3 on current10s.

I've now got an overview: seven packages do not compile:

http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/

m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
IMO they should compile with cc, too, though.

I'm off again now and may have a look again later,

Olaf

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

> This will be easy. Several options.
>
>  - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>    Since they probably did, compiling gcc with Sun cc is something   
> people are interested/willing to do.
>
>  - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>
>  - Maybe just change your $PATH, but I'd prefer previous.
>
> Later.
>
>  - Jay
>
>
> ----------------------------------------
>> Date: Thu, 13 May 2010 16:05:21 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>> Subject: RE: [M3devel] OpenCSW build farm access
>>
>> I finally managed to get CVS working.
>>
>> I postponed current9s and set up some jobs on current10s, as that
>> should be equivalent to your machine, Jay.
>>
>> However, compilation of the cm3cg1 backed fails:
>>
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>
>> Can you have a look?
>>
>> TIA,
>>
>> 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 May 14 08:27:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 06:27:49 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>, ,
	<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>, ,
	<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>, ,
	<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>, ,
	<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>, ,
	<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>, ,
	<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>, ,
	<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>, ,
	<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>, ,
	<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>, ,
	<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>, ,
	<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>, ,
	<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>, ,
	<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>, ,
	<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>, ,
	<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>, ,
	<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>, ,
	<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>, ,
	<20100511090214.5bsr2f24o4os, , !, cg88@mai l,.,eleg os of ,,
	t, , .com>, , <F6, 43890B-0,
	0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>, ,
	<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>, ,
	<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>, ,
	<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>, ,
	<20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>,
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>,
	<20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>
Message-ID: <COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>


Having to use gcc to compile gcc and gdb is not new, and is probably the way it has always been (from our point of view).
There is even configuration around, how to run gcc and what flags to give it, separate from SYSTEM_CC.

However, I do believe current gcc can be built with Sun cc. But I vaguely recall the patches aren't small.
I'll see.

It looks like opengl failed..and if this wasn't release branch, I'd say I broke it..
I'll look more either way.

I don't know what's up with this "libstable" stuff but I'll look more.
Could maybe be just lack of postgres or something?

More later (or maybe just commits).

?- Jay

----------------------------------------
> Date: Fri, 14 May 2010 07:52:45 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
> Subject: RE: [M3devel] OpenCSW build farm access
>
> Hi again,
>
> with some tweaking, some `standard' Hudson jobs have now complete
> for cm3 on current10s.
>
> I've now got an overview: seven packages do not compile:
>
> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/
>
> m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
> IMO they should compile with cc, too, though.
>
> I'm off again now and may have a look again later,
>
> Olaf
>
> Quoting Jay K :
>
>> This will be easy. Several options.
>>
>> - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>> Since they probably did, compiling gcc with Sun cc is something
>> people are interested/willing to do.
>>
>> - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>>
>> - Maybe just change your $PATH, but I'd prefer previous.
>>
>> Later.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> Date: Thu, 13 May 2010 16:05:21 +0200
>>> From: wagner at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>
>>> I finally managed to get CVS working.
>>>
>>> I postponed current9s and set up some jobs on current10s, as that
>>> should be equivalent to your machine, Jay.
>>>
>>> However, compilation of the cm3cg1 backed fails:
>>>
>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>>
>>> Can you have a look?
>>>
>>> TIA,
>>>
>>> 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 May 14 08:37:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 06:37:07 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
Message-ID: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>


I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).

SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
? The data in the assembly looks like. Maybe a runtime memory corruption.


PPC32_OPENBSD complains something like in TextCat that a type is missing.
?I think it used to mostly work since I deleted some install I had there.


SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
(gdb) disassem
Dump of assembler code for function RTLinker__InitRuntime:
0x00000000004bd01c <RTLinker__InitRuntime+0>:?? save? %sp, -224, %sp
0x00000000004bd020 <RTLinker__InitRuntime+4>:?? sethi? %hi(0xd18800), %l7
0x00000000004bd024 <RTLinker__InitRuntime+8>:?? add? %l7, 0x1fc, %l7??? ! 0xd189fc
0x00000000004bd028 <RTLinker__InitRuntime+12>:? call? 0x4bd010 <_m3_fault+60> 
0x00000000004bd02c <RTLinker__InitRuntime+16>:? nop 
0x00000000004bd030 <RTLinker__InitRuntime+20>:? stx? %i0, [ %fp + 0x87f ]
0x00000000004bd034 <RTLinker__InitRuntime+24>:? stx? %i1, [ %fp + 0x887 ]
0x00000000004bd038 <RTLinker__InitRuntime+28>:? stx? %i2, [ %fp + 0x88f ]
0x00000000004bd03c <RTLinker__InitRuntime+32>:? stx? %i3, [ %fp + 0x897 ]
0x00000000004bd040 <RTLinker__InitRuntime+36>:? sethi? %hi(0x942c00), %g1
0x00000000004bd044 <RTLinker__InitRuntime+40>:? or? %g1, 0x290, %g1???? ! 0x942e90 <MM_RTLinker>
0x00000000004bd048 <RTLinker__InitRuntime+44>:? ldx? [ %l7 + %g1 ], %g1? << here


This seems like it'll be tough going. :(


I think I'll try with PIC? turned off.

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Fri May 14 09:25:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 07:25:30 +0000
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	,,<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>,
	,,<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	,,<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>,
	,,<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>,
	,,<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>,
	,,<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>,
	,,<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>,
	,,<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>,
	,,<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>,
	,,<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>,
	,,<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>,
	,,<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>,
	,,<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>,
	,,<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>,
	,,<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>,
	,,<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>,
	,,<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>,
	, , <20100511090214.5bsr2f24o4os, , !, cg88@mai l, ., eleg os of , , , t,
	, .com>, 
	, <F6, 43890B-0,,0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>,
	,,<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>,
	,,<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>,
	,,<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>,
	, , <20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>, ,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>, ,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>, ,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>, ,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>, ,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>, ,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>, ,
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>, ,
	<20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>,
	<COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>
Message-ID: <COL101-W48E4F207218CBFA9DF43E3E6FD0@phx.gbl>


Olaf, it looks like the "build" part only builds "core".
Unless there is an error, then it builds more.
Isn't that wrong?

Anyway, I can see the "test" part tries to build everything anyway, and it fails creating the symlink libopengl.so.5.
Wierd.

I'll see if I can reproduce this.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com
> Date: Fri, 14 May 2010 06:27:49 +0000
> CC: m3devel at elegosoft.com; trygvis at opencsw.org; dam at baltic-online.de
> Subject: Re: [M3devel] OpenCSW build farm access
>
>
> Having to use gcc to compile gcc and gdb is not new, and is probably the way it has always been (from our point of view).
> There is even configuration around, how to run gcc and what flags to give it, separate from SYSTEM_CC.
>
> However, I do believe current gcc can be built with Sun cc. But I vaguely recall the patches aren't small.
> I'll see.
>
> It looks like opengl failed..and if this wasn't release branch, I'd say I broke it..
> I'll look more either way.
>
> I don't know what's up with this "libstable" stuff but I'll look more.
> Could maybe be just lack of postgres or something?
>
> More later (or maybe just commits).
>
>  - Jay
>
> ----------------------------------------
>> Date: Fri, 14 May 2010 07:52:45 +0200
>> From: wagner at elegosoft.com
>> To: jay.krell at cornell.edu
>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>> Subject: RE: [M3devel] OpenCSW build farm access
>>
>> Hi again,
>>
>> with some tweaking, some `standard' Hudson jobs have now complete
>> for cm3 on current10s.
>>
>> I've now got an overview: seven packages do not compile:
>>
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/
>>
>> m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
>> IMO they should compile with cc, too, though.
>>
>> I'm off again now and may have a look again later,
>>
>> Olaf
>>
>> Quoting Jay K :
>>
>>> This will be easy. Several options.
>>>
>>> - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>>> Since they probably did, compiling gcc with Sun cc is something
>>> people are interested/willing to do.
>>>
>>> - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>>>
>>> - Maybe just change your $PATH, but I'd prefer previous.
>>>
>>> Later.
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> Date: Thu, 13 May 2010 16:05:21 +0200
>>>> From: wagner at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>>
>>>> I finally managed to get CVS working.
>>>>
>>>> I postponed current9s and set up some jobs on current10s, as that
>>>> should be equivalent to your machine, Jay.
>>>>
>>>> However, compilation of the cm3cg1 backed fails:
>>>>
>>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>>>
>>>> Can you have a look?
>>>>
>>>> TIA,
>>>>
>>>> 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 May 14 11:08:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 09:08:58 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>
Message-ID: <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>


Hm. Something is wrong on many platforms, in head, at least with my boot archives.
? PPC_DARWIN, SOLsun, I386_LINUX
I'll figure it out. Hopefully soon.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Fri, 14 May 2010 06:37:07 +0000
> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>
> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>   The data in the assembly looks like. Maybe a runtime memory corruption.
>
>
> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>  I think it used to mostly work since I deleted some install I had there.
>
>
> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
> (gdb) disassem
> Dump of assembler code for function RTLinker__InitRuntime:
> 0x00000000004bd01c :   save  %sp, -224, %sp
> 0x00000000004bd020 :   sethi  %hi(0xd18800), %l7
> 0x00000000004bd024 :   add  %l7, 0x1fc, %l7    ! 0xd189fc
> 0x00000000004bd028 :  call  0x4bd010 <_m3_fault+60>
> 0x00000000004bd02c :  nop
> 0x00000000004bd030 :  stx  %i0, [ %fp + 0x87f ]
> 0x00000000004bd034 :  stx  %i1, [ %fp + 0x887 ]
> 0x00000000004bd038 :  stx  %i2, [ %fp + 0x88f ]
> 0x00000000004bd03c :  stx  %i3, [ %fp + 0x897 ]
> 0x00000000004bd040 :  sethi  %hi(0x942c00), %g1
> 0x00000000004bd044 :  or  %g1, 0x290, %g1     ! 0x942e90 
> 0x00000000004bd048 :  ldx  [ %l7 + %g1 ], %g1  << here
>
>
> This seems like it'll be tough going. :(
>
>
> I think I'll try with PIC  turned off.
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Fri May 14 12:27:36 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 10:27:36 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>
Message-ID: <COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>


ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
Then I'll have to narrow it down some -- there are two main sets of changes:
?- my changes to set operations ? 
?- my change to div/mod
?- Tony's to bit field operations? 

It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.

I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
to keep them if they don't work.
?(Well, hopefully the NT386 versions can stay. :) )

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Fri, 14 May 2010 09:08:58 +0000
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>   PPC_DARWIN, SOLsun, I386_LINUX
> I'll figure it out. Hopefully soon.
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Fri, 14 May 2010 06:37:07 +0000
>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>
>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>
>>
>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>> I think it used to mostly work since I deleted some install I had there.
>>
>>
>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>> (gdb) disassem
>> Dump of assembler code for function RTLinker__InitRuntime:
>> 0x00000000004bd01c : save %sp, -224, %sp
>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>> 0x00000000004bd02c : nop
>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>
>>
>> This seems like it'll be tough going. :(
>>
>>
>> I think I'll try with PIC turned off.
>>
>> - Jay
>>
>>
>
 		 	   		  

From hosking at cs.purdue.edu  Fri May 14 15:59:02 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 14 May 2010 09:59:02 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>
Message-ID: <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>

Argh.  I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.

Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels.  I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution.  This is fragile stuff... and it may just be a bug in gcc that we are exercising.

It may be that we just need to update the backend to a newer version of gcc.  It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been.  Problem is that newer gcc may not play nice with older targets.  I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.

On 14 May 2010, at 06:27, Jay K wrote:

> 
> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
> Then I'll have to narrow it down some -- there are two main sets of changes:
>  - my changes to set operations   
>  - my change to div/mod
>  - Tony's to bit field operations  
> 
> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
> 
> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
> to keep them if they don't work.
>  (Well, hopefully the NT386 versions can stay. :) )
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Fri, 14 May 2010 09:08:58 +0000
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>  PPC_DARWIN, SOLsun, I386_LINUX
>> I'll figure it out. Hopefully soon.
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> 
>>> 
>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>> 
>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>> 
>>> 
>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>> I think it used to mostly work since I deleted some install I had there.
>>> 
>>> 
>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>> (gdb) disassem
>>> Dump of assembler code for function RTLinker__InitRuntime:
>>> 0x00000000004bd01c : save %sp, -224, %sp
>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>> 0x00000000004bd02c : nop
>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>> 
>>> 
>>> This seems like it'll be tough going. :(
>>> 
>>> 
>>> I think I'll try with PIC turned off.
>>> 
>>> - Jay
>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Fri May 14 19:58:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 17:58:29 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>
Message-ID: <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>


I don't think anything I've been fiddling with has been dropped by gcc, yet.
?I might have depended on Irix o32 to get up to a working gcc, but no matter.
?I agree if they drop it, we have to.
?Though we could also keep multiple gcc versions if there was really something we wanted,
? but that's not likely.
?A C generating backend also solves this.


I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
But I won't guarantee that now and am very willing to undo them if there is a problem.
?(big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).


?I don't remember about div/mod.
?While it seems "obvious" that the change is correct, it could be that that part of
?gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?


I'm also not optimizing at all.


I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
easily, and I'm also not keen on the huge testing matrix.
(I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)


If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.


Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
?SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).


?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 09:59:02 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>
> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>
> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>
> On 14 May 2010, at 06:27, Jay K wrote:
>
>>
>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>> Then I'll have to narrow it down some -- there are two main sets of changes:
>> - my changes to set operations
>> - my change to div/mod
>> - Tony's to bit field operations
>>
>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>
>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>> to keep them if they don't work.
>> (Well, hopefully the NT386 versions can stay. :) )
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>> PPC_DARWIN, SOLsun, I386_LINUX
>>> I'll figure it out. Hopefully soon.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>
>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>
>>>>
>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>> I think it used to mostly work since I deleted some install I had there.
>>>>
>>>>
>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>> (gdb) disassem
>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>> 0x00000000004bd02c : nop
>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>
>>>>
>>>> This seems like it'll be tough going. :(
>>>>
>>>>
>>>> I think I'll try with PIC turned off.
>>>>
>>>> - Jay
>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Fri May 14 20:25:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 18:25:59 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>,
	, , <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
Message-ID: <COL101-W19A08D5003AAF4F70340CCE6FD0@phx.gbl>


I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.


I have some extra time today, so, plan:
? retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
? test undo just the bitfield insert/extract change, see if that is the problem 
? work through the others if not 
? Possibly verify mod/div test coverage (unless it is the problem, in which
? case if I put it back, no need for test coverage, probably nobody will ever
? touch it again, which is fine. :) )
?I'm pretty sure I tested the set stuff well because I was very nervous but
? if others are ruled out I'll undo or test it.
? (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
?set changes. Only through experimentation/testing could I know that
?the definition of bit indices matched up between hand.c and the btc/bts instructions,
?it appeared to be a very convenient coincidence.)


I am surprised that I386_* working and broken.
I would think wordsize and endian is all that matters here.


I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
But moving up to 4.4.x or 4.5.x is welcome too. :)


?- Jay
?

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 17:58:29 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>  I might have depended on Irix o32 to get up to a working gcc, but no matter.
>  I agree if they drop it, we have to.
>  Though we could also keep multiple gcc versions if there was really something we wanted,
>   but that's not likely.
>  A C generating backend also solves this.
>
>
> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
> But I won't guarantee that now and am very willing to undo them if there is a problem.
>  (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>
>
>  I don't remember about div/mod.
>  While it seems "obvious" that the change is correct, it could be that that part of
>  gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>
>
> I'm also not optimizing at all.
>
>
> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
> easily, and I'm also not keen on the huge testing matrix.
> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>
>
> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>
>
> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>  SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>
>
>  - Jay
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 09:59:02 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>
>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>
>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>
>> On 14 May 2010, at 06:27, Jay K wrote:
>>
>>>
>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>> - my changes to set operations
>>> - my change to div/mod
>>> - Tony's to bit field operations
>>>
>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>
>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>> to keep them if they don't work.
>>> (Well, hopefully the NT386 versions can stay. :) )
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>> I'll figure it out. Hopefully soon.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: m3devel at elegosoft.com
>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>
>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>
>>>>>
>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>
>>>>>
>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>> (gdb) disassem
>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>> 0x00000000004bd02c : nop
>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>
>>>>>
>>>>> This seems like it'll be tough going. :(
>>>>>
>>>>>
>>>>> I think I'll try with PIC turned off.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From wagner at elegosoft.com  Sat May 15 00:09:13 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Sat, 15 May 2010 00:09:13 +0200
Subject: [M3devel] OpenCSW build farm access
In-Reply-To: <COL101-W48E4F207218CBFA9DF43E3E6FD0@phx.gbl>
References: <C2A672E3-8245-407C-B529-A1F5AD870A62@opencsw.org>,
	,,<20100503171916.eayc9vjs0k0cgokc@mail.elegosoft.com>,
	,,<COL101-W37F54C52C83A19921C34F9E6F20@phx.gbl>,
	,,<23FA70B3-7FF1-40F2-A0C9-F1B54C667E7B@opencsw.org>,
	,,<COL101-W264C3C66AA17F89E4CB618E6F20@phx.gbl>,
	,,<D43511AF-92A9-4772-B697-0E607B4534AC@opencsw.org>,
	,,<FF0F4CCA-1361-4B93-92AE-B662DAA1D8A0@baltic-online.de>,
	,,<COL101-W16F25F18A8256D96D5A8E1E6F50@phx.gbl>,
	,,<57E26EE8-3A1F-4858-930C-806810307231@baltic-online.de>,
	,,<COL101-W35F65C9AA3476C2C8355CFE6F50@phx.gbl>,
	,,<387D3D1B-79FF-41D5-B081-630B242576F5@baltic-online.de>,
	,,<COL101-W42B1DC6849E33F45D784DEE6F50@phx.gbl>,
	,,<9174FC64-33FE-4660-A90E-3164147E23D7@baltic-online.de>,
	,,<20100507102032.1b4cyj5r6s4gwcws@mail.elegosoft.com>,
	,,<20100507102946.xx5cdc1gcgkgoko0@mail.elegosoft.com>,
	,,<21CD9B27-527D-4774-90FC-F3D5A459FE81@baltic-online.de>,
	,,<20100510192719.kttwtckjokswgwog@mail.elegosoft.com>,
	,,<DB4D88B3-4766-4BA0-A79B-2AB5DAAFACE5@baltic-online.de>,
	, , <20100511090214.5bsr2f24o4os, , !, cg88@mai l, ., eleg os of , , , t,
	, .com>, 
	, <F6, 43890B-0,,0C6-4A4B-861E-1F11B965BFB9@baltic-online.de>,
	,,<20100511195429.put1evef40ow8ssk@mail.elegosoft.com>,
	,,<COL101-W30C106C4565C5D0F4A6417E6FA0@phx.gbl>,
	,,<3B6ECA23-1E04-405D-906E-0F97B9C8B1CC@baltic-online.de>,
	, , <20100511224714.i1ivm5jzksg4c8oc@mail.elegosoft.com>, ,
	<COL101-W620105CB7B46040EDD1DE1E6FA0@phx.gbl>, ,
	<20100512085124.yf9ait5ts0gw4og8@mail.elegosoft.com>, ,
	<COL101-W17C4F299CF310B431840BFE6FB0@phx.gbl>, ,
	<CE17528C-0506-44F6-814F-5CDD30A82208@baltic-online.de>, ,
	<COL101-W53F8AA82D1BF6A4E56A1EAE6FB0@phx.gbl>, ,
	<20100513160521.bpopjkn2o0wsgo88@mail.elegosoft.com>, ,
	<COL101-W33D37F9D755A24A0B40408E6FC0@phx.gbl>, ,
	<20100514075245.p04iiok0e8gsokw0@mail.elegosoft.com>,
	<COL101-W16325DB13F596BD9152FE7E6FD0@phx.gbl>
	<COL101-W48E4F207218CBFA9DF43E3E6FD0@phx.gbl>
Message-ID: <20100515000913.3zzs4eu40swsgg0k@mail.elegosoft.com>

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

> Olaf, it looks like the "build" part only builds "core".
> Unless there is an error, then it builds more.
> Isn't that wrong?

I think it's always build just core. Why should it build more in case
of an error?

All packages are built and tested in the test-all-pkgs jobs.

> Anyway, I can see the "test" part tries to build everything anyway,   
> and it fails creating the symlink libopengl.so.5.
> Wierd.
>
> I'll see if I can reproduce this.

Strange. But to answer a question from your previous mail,
this is still the release branch. I just tried to port the existing
jobs now running on your machine first.

We can easily switch them to the trunk head though.

Olaf

> ?- Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: wagner at elegosoft.com
>> Date: Fri, 14 May 2010 06:27:49 +0000
>> CC: m3devel at elegosoft.com; trygvis at opencsw.org; dam at baltic-online.de
>> Subject: Re: [M3devel] OpenCSW build farm access
>>
>>
>> Having to use gcc to compile gcc and gdb is not new, and is   
>> probably the way it has always been (from our point of view).
>> There is even configuration around, how to run gcc and what flags   
>> to give it, separate from SYSTEM_CC.
>>
>> However, I do believe current gcc can be built with Sun cc. But I   
>> vaguely recall the patches aren't small.
>> I'll see.
>>
>> It looks like opengl failed..and if this wasn't release branch, I'd  
>>  say I broke it..
>> I'll look more either way.
>>
>> I don't know what's up with this "libstable" stuff but I'll look more.
>> Could maybe be just lack of postgres or something?
>>
>> More later (or maybe just commits).
>>
>>  - Jay
>>
>> ----------------------------------------
>>> Date: Fri, 14 May 2010 07:52:45 +0200
>>> From: wagner at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>
>>> Hi again,
>>>
>>> with some tweaking, some `standard' Hudson jobs have now complete
>>> for cm3 on current10s.
>>>
>>> I've now got an overview: seven packages do not compile:
>>>
>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/lastBuild/testReport/
>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-test-all-pkgs-SOLsun-opencsw-current10s/
>>>
>>> m3cc (and probably m3gdb) can be `fixed' by using gcc instead of Sun cc.
>>> IMO they should compile with cc, too, though.
>>>
>>> I'm off again now and may have a look again later,
>>>
>>> Olaf
>>>
>>> Quoting Jay K :
>>>
>>>> This will be easy. Several options.
>>>>
>>>> - Look at 4.5.0 and how they fixed it to compile with Sun cc.
>>>> Since they probably did, compiling gcc with Sun cc is something
>>>> people are interested/willing to do.
>>>>
>>>> - Take m3makefile/gnucc.common/gmake.common from head to point it at gcc.
>>>>
>>>> - Maybe just change your $PATH, but I'd prefer previous.
>>>>
>>>> Later.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Thu, 13 May 2010 16:05:21 +0200
>>>>> From: wagner at elegosoft.com
>>>>> To: jay.krell at cornell.edu
>>>>> CC: dam at baltic-online.de; m3devel at elegosoft.com; trygvis at opencsw.org
>>>>> Subject: RE: [M3devel] OpenCSW build farm access
>>>>>
>>>>> I finally managed to get CVS working.
>>>>>
>>>>> I postponed current9s and set up some jobs on current10s, as that
>>>>> should be equivalent to your machine, Jay.
>>>>>
>>>>> However, compilation of the cm3cg1 backed fails:
>>>>>
>>>>> http://hudson.modula3.com:8080/view/SOLsun/job/cm3-m3cc-SOLsun-opencsw-current10s/4/console
>>>>>
>>>>> Can you have a look?
>>>>>
>>>>> TIA,
>>>>>
>>>>> 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
>>>
>>
>



-- 
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  Sat May 15 00:13:58 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 14 May 2010 22:13:58 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>
Message-ID: <COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>


So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....

? - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
> Date: Fri, 14 May 2010 18:25:59 +0000
>
>
> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>
>
> I have some extra time today, so, plan:
>   retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>   test undo just the bitfield insert/extract change, see if that is the problem
>   work through the others if not
>   Possibly verify mod/div test coverage (unless it is the problem, in which
>   case if I put it back, no need for test coverage, probably nobody will ever
>   touch it again, which is fine. :) )
>  I'm pretty sure I tested the set stuff well because I was very nervous but
>   if others are ruled out I'll undo or test it.
>   (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>  set changes. Only through experimentation/testing could I know that
>  the definition of bit indices matched up between hand.c and the btc/bts instructions,
>  it appeared to be a very convenient coincidence.)
>
>
> I am surprised that I386_* working and broken.
> I would think wordsize and endian is all that matters here.
>
>
> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
> But moving up to 4.4.x or 4.5.x is welcome too. :)
>
>
>  - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 17:58:29 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>> I agree if they drop it, we have to.
>> Though we could also keep multiple gcc versions if there was really something we wanted,
>> but that's not likely.
>> A C generating backend also solves this.
>>
>>
>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>
>>
>> I don't remember about div/mod.
>> While it seems "obvious" that the change is correct, it could be that that part of
>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>
>>
>> I'm also not optimizing at all.
>>
>>
>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>> easily, and I'm also not keen on the huge testing matrix.
>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>
>>
>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>
>>
>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>
>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>
>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>
>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>
>>>>
>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>> - my changes to set operations
>>>> - my change to div/mod
>>>> - Tony's to bit field operations
>>>>
>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>
>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>> to keep them if they don't work.
>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: m3devel at elegosoft.com
>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>> I'll figure it out. Hopefully soon.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: m3devel at elegosoft.com
>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>
>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>
>>>>>>
>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>
>>>>>>
>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>> (gdb) disassem
>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>> 0x00000000004bd02c : nop
>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>
>>>>>>
>>>>>> This seems like it'll be tough going. :(
>>>>>>
>>>>>>
>>>>>> I think I'll try with PIC turned off.
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 02:24:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 00:24:03 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>,
	, , <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>
Message-ID: <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>


Tony I think it is your change to extract_mn.
Try it with SOLsun for example.
I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):


diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
77,78c77,78
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 22, %g1
> ??? srl??? %g1, 31, %g1
118,119c118,119
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 22, %g1
> ??? srl??? %g1, 31, %g1
197,198c197,198
< ??? srl??? %g1, 21, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 21, %g1
> ??? srl??? %g1, 31, %g1
236,237c236,237
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1
---
> ??? sll??? %g1, 22, %g1
> ??? srl??? %g1, 31, %g1
273,274c273,274
< ??? srl??? %g1, 22, %g1
< ??? and??? %g1, 1, %g1


This is not optimized.
They seem equally optimal, but very different.
? Assuming shifts are fast. Could be srl+and is faster than sll+srl.
? srl+and is clearer.
?I don't remember which of these worked.


< ??? srl??? %g1, 22, %g1

< ??? and??? %g1, 1, %g1

---

> ??? sll??? %g1, 22, %g1

> ??? srl??? %g1, 31, %g1



I read the first as:
? extract bit 22, plus or minus 1
vs.
? extract bit 32-22=10, plus or minus 1.


It would probably be ok to move bits around, but insert would have to match.


?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Fri, 14 May 2010 22:13:58 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>
>   - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> Date: Fri, 14 May 2010 18:25:59 +0000
>>
>>
>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>
>>
>> I have some extra time today, so, plan:
>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>> test undo just the bitfield insert/extract change, see if that is the problem
>> work through the others if not
>> Possibly verify mod/div test coverage (unless it is the problem, in which
>> case if I put it back, no need for test coverage, probably nobody will ever
>> touch it again, which is fine. :) )
>> I'm pretty sure I tested the set stuff well because I was very nervous but
>> if others are ruled out I'll undo or test it.
>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>> set changes. Only through experimentation/testing could I know that
>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>> it appeared to be a very convenient coincidence.)
>>
>>
>> I am surprised that I386_* working and broken.
>> I would think wordsize and endian is all that matters here.
>>
>>
>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>> I agree if they drop it, we have to.
>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>> but that's not likely.
>>> A C generating backend also solves this.
>>>
>>>
>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>
>>>
>>> I don't remember about div/mod.
>>> While it seems "obvious" that the change is correct, it could be that that part of
>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>
>>>
>>> I'm also not optimizing at all.
>>>
>>>
>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>> easily, and I'm also not keen on the huge testing matrix.
>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>
>>>
>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>
>>>
>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>
>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>
>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>
>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>
>>>>>
>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>> - my changes to set operations
>>>>> - my change to div/mod
>>>>> - Tony's to bit field operations
>>>>>
>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>
>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>> to keep them if they don't work.
>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: m3devel at elegosoft.com
>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>> I'll figure it out. Hopefully soon.
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>
>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>
>>>>>>>
>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>
>>>>>>>
>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>> (gdb) disassem
>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>> 0x00000000004bd02c : nop
>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>
>>>>>>>
>>>>>>> This seems like it'll be tough going. :(
>>>>>>>
>>>>>>>
>>>>>>> I think I'll try with PIC turned off.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 03:07:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 01:07:27 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,
	, , , , <COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , 
	, <01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,
	, , <COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
Message-ID: <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>


> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1

Er.
first: a = (a>> 22) & 1;
second: a = (a << 22)>> 31;

are actually darn close, maybe the same.
Let's just be lame and test in C:

#include <stdio.h>
int main()
{
unsigned a = ~0;
unsigned b = (a>> 22) & 1;
unsigned c = (a << 22)>> 31;
printf("%x %x\n", b, c);
return 0;
}

both print 1. So I remain a bit uncertain.
I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
I might dig more before commiting the undo.
Maybe bit fields of multiple bits are the only ones broken.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:24:03 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> Tony I think it is your change to extract_mn.
> Try it with SOLsun for example.
> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>
>
> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
> 77,78c77,78
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 118,119c118,119
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 197,198c197,198
> <     srl    %g1, 21, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 21, %g1
>>     srl    %g1, 31, %g1
> 236,237c236,237
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 273,274c273,274
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
>
>
> This is not optimized.
> They seem equally optimal, but very different.
>   Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>   srl+and is clearer.
>  I don't remember which of these worked.
>
>
> <     srl    %g1, 22, %g1
>
> <     and    %g1, 1, %g1
>
> ---
>
>>     sll    %g1, 22, %g1
>
>>     srl    %g1, 31, %g1
>
>
>
> I read the first as:
>   extract bit 22, plus or minus 1
> vs.
>   extract bit 32-22=10, plus or minus 1.
>
>
> It would probably be ok to move bits around, but insert would have to match.
>
>
>  - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 22:13:58 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>
>>>
>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>
>>>
>>> I have some extra time today, so, plan:
>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>> test undo just the bitfield insert/extract change, see if that is the problem
>>> work through the others if not
>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>> case if I put it back, no need for test coverage, probably nobody will ever
>>> touch it again, which is fine. :) )
>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>> if others are ruled out I'll undo or test it.
>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>> set changes. Only through experimentation/testing could I know that
>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>> it appeared to be a very convenient coincidence.)
>>>
>>>
>>> I am surprised that I386_* working and broken.
>>> I would think wordsize and endian is all that matters here.
>>>
>>>
>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>> I agree if they drop it, we have to.
>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>> but that's not likely.
>>>> A C generating backend also solves this.
>>>>
>>>>
>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>
>>>>
>>>> I don't remember about div/mod.
>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>
>>>>
>>>> I'm also not optimizing at all.
>>>>
>>>>
>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>> easily, and I'm also not keen on the huge testing matrix.
>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>
>>>>
>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>
>>>>
>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>
>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>
>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>
>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>
>>>>>>
>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>> - my changes to set operations
>>>>>> - my change to div/mod
>>>>>> - Tony's to bit field operations
>>>>>>
>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>
>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>> to keep them if they don't work.
>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>
>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>
>>>>>>>>
>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>
>>>>>>>>
>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>> (gdb) disassem
>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>
>>>>>>>>
>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>
>>>>>>>>
>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 03:29:01 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 01:29:01 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,,, , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , ,,,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,,, ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,
	, , <COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
Message-ID: <COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>


Well I'm feeling dumb. That test case surely would print 1 for almost anything.
A more accurate one, which shows a problem, is:

#include <stdio.h>

unsigned F1(unsigned a) { return ((a>> 22) & 1); }
unsigned F2(unsigned a) { return ((a << 22)>> 31); }

int main()
{
??? unsigned a = 1 << 22;
??? printf("%x %x\n", F1(a), F2(a));
??? return 0;
}

But I'm still having trouble convincing myself.
I guess the second might give you the 10th bit.
Er, the 9th.

#include <stdio.h>

unsigned F1(unsigned a) { return ((a>> 22) & 1); }
unsigned F2(unsigned a) { return ((a << 22)>> 31); }

int main()
{
??? unsigned a = 1 << 22;
??? printf("%x %x\n", F1(a), F2(a));

??? a = 1 << 9;
??? printf("%x %x\n", F1(a), F2(a));
??? return 0;
}

1 0
0 1

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 01:07:27 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>
> Er.
> first: a = (a>> 22) & 1;
> second: a = (a << 22)>> 31;
>
> are actually darn close, maybe the same.
> Let's just be lame and test in C:
>
> #include 
> int main()
> {
> unsigned a = ~0;
> unsigned b = (a>> 22) & 1;
> unsigned c = (a << 22)>> 31;
> printf("%x %x\n", b, c);
> return 0;
> }
>
> both print 1. So I remain a bit uncertain.
> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
> I might dig more before commiting the undo.
> Maybe bit fields of multiple bits are the only ones broken.
>
>  - Jay
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 00:24:03 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>> Tony I think it is your change to extract_mn.
>> Try it with SOLsun for example.
>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>
>>
>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>> 77,78c77,78
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>> 118,119c118,119
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>> 197,198c197,198
>> < srl %g1, 21, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 21, %g1
>>> srl %g1, 31, %g1
>> 236,237c236,237
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>> ---
>>> sll %g1, 22, %g1
>>> srl %g1, 31, %g1
>> 273,274c273,274
>> < srl %g1, 22, %g1
>> < and %g1, 1, %g1
>>
>>
>> This is not optimized.
>> They seem equally optimal, but very different.
>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>> srl+and is clearer.
>> I don't remember which of these worked.
>>
>>
>> < srl %g1, 22, %g1
>>
>> < and %g1, 1, %g1
>>
>> ---
>>
>>> sll %g1, 22, %g1
>>
>>> srl %g1, 31, %g1
>>
>>
>>
>> I read the first as:
>> extract bit 22, plus or minus 1
>> vs.
>> extract bit 32-22=10, plus or minus 1.
>>
>>
>> It would probably be ok to move bits around, but insert would have to match.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>
>>>>
>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>
>>>>
>>>> I have some extra time today, so, plan:
>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>> work through the others if not
>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>> touch it again, which is fine. :) )
>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>> if others are ruled out I'll undo or test it.
>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>> set changes. Only through experimentation/testing could I know that
>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>> it appeared to be a very convenient coincidence.)
>>>>
>>>>
>>>> I am surprised that I386_* working and broken.
>>>> I would think wordsize and endian is all that matters here.
>>>>
>>>>
>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>> I agree if they drop it, we have to.
>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>> but that's not likely.
>>>>> A C generating backend also solves this.
>>>>>
>>>>>
>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>
>>>>>
>>>>> I don't remember about div/mod.
>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>
>>>>>
>>>>> I'm also not optimizing at all.
>>>>>
>>>>>
>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>
>>>>>
>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>
>>>>>
>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>
>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>
>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>
>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>
>>>>>>>
>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>> - my changes to set operations
>>>>>>> - my change to div/mod
>>>>>>> - Tony's to bit field operations
>>>>>>>
>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>
>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>> to keep them if they don't work.
>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>
>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>> (gdb) disassem
>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 05:10:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 03:10:54 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, ,,, , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, ,
	,,,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, ,
	,,,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>,,,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,,, ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>,
	, , <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>
Message-ID: <COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>


http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html

BIT_FIELD_REF considered harmful

We should try to use COMPONENT_REF instead.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 01:29:01 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
> A more accurate one, which shows a problem, is:
>
> #include 
>
> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>
> int main()
> {
>     unsigned a = 1 << 22;
>     printf("%x %x\n", F1(a), F2(a));
>     return 0;
> }
>
> But I'm still having trouble convincing myself.
> I guess the second might give you the 10th bit.
> Er, the 9th.
>
> #include 
>
> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>
> int main()
> {
>     unsigned a = 1 << 22;
>     printf("%x %x\n", F1(a), F2(a));
>
>     a = 1 << 9;
>     printf("%x %x\n", F1(a), F2(a));
>     return 0;
> }
>
> 1 0
> 0 1
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 01:07:27 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>
>> Er.
>> first: a = (a>> 22) & 1;
>> second: a = (a << 22)>> 31;
>>
>> are actually darn close, maybe the same.
>> Let's just be lame and test in C:
>>
>> #include
>> int main()
>> {
>> unsigned a = ~0;
>> unsigned b = (a>> 22) & 1;
>> unsigned c = (a << 22)>> 31;
>> printf("%x %x\n", b, c);
>> return 0;
>> }
>>
>> both print 1. So I remain a bit uncertain.
>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>> I might dig more before commiting the undo.
>> Maybe bit fields of multiple bits are the only ones broken.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Tony I think it is your change to extract_mn.
>>> Try it with SOLsun for example.
>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>
>>>
>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>> 77,78c77,78
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>> 118,119c118,119
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>> 197,198c197,198
>>> < srl %g1, 21, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 21, %g1
>>>> srl %g1, 31, %g1
>>> 236,237c236,237
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>> ---
>>>> sll %g1, 22, %g1
>>>> srl %g1, 31, %g1
>>> 273,274c273,274
>>> < srl %g1, 22, %g1
>>> < and %g1, 1, %g1
>>>
>>>
>>> This is not optimized.
>>> They seem equally optimal, but very different.
>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>> srl+and is clearer.
>>> I don't remember which of these worked.
>>>
>>>
>>> < srl %g1, 22, %g1
>>>
>>> < and %g1, 1, %g1
>>>
>>> ---
>>>
>>>> sll %g1, 22, %g1
>>>
>>>> srl %g1, 31, %g1
>>>
>>>
>>>
>>> I read the first as:
>>> extract bit 22, plus or minus 1
>>> vs.
>>> extract bit 32-22=10, plus or minus 1.
>>>
>>>
>>> It would probably be ok to move bits around, but insert would have to match.
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>
>>>>>
>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>
>>>>>
>>>>> I have some extra time today, so, plan:
>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>> work through the others if not
>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>> touch it again, which is fine. :) )
>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>> if others are ruled out I'll undo or test it.
>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>> set changes. Only through experimentation/testing could I know that
>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>> it appeared to be a very convenient coincidence.)
>>>>>
>>>>>
>>>>> I am surprised that I386_* working and broken.
>>>>> I would think wordsize and endian is all that matters here.
>>>>>
>>>>>
>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>> I agree if they drop it, we have to.
>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>> but that's not likely.
>>>>>> A C generating backend also solves this.
>>>>>>
>>>>>>
>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>
>>>>>>
>>>>>> I don't remember about div/mod.
>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>
>>>>>>
>>>>>> I'm also not optimizing at all.
>>>>>>
>>>>>>
>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>
>>>>>>
>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>
>>>>>>
>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: hosking at cs.purdue.edu
>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>
>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>
>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>
>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>> - my changes to set operations
>>>>>>>> - my change to div/mod
>>>>>>>> - Tony's to bit field operations
>>>>>>>>
>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>
>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>> to keep them if they don't work.
>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>
>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>> (gdb) disassem
>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From hosking at cs.purdue.edu  Sat May 15 06:13:20 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 00:13:20 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
Message-ID: <00A2CBB5-0BD0-43B0-8C2B-5D7296048DAF@cs.purdue.edu>

Yeah.   Looks broken.  Please de-optimize extract_mn to what it was before.

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 14 May 2010, at 20:24, Jay K wrote:

> 
> Tony I think it is your change to extract_mn.
> Try it with SOLsun for example.
> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
> 
> 
> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
> 77,78c77,78
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 118,119c118,119
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 197,198c197,198
> <     srl    %g1, 21, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 21, %g1
>>     srl    %g1, 31, %g1
> 236,237c236,237
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> ---
>>     sll    %g1, 22, %g1
>>     srl    %g1, 31, %g1
> 273,274c273,274
> <     srl    %g1, 22, %g1
> <     and    %g1, 1, %g1
> 
> 
> This is not optimized.
> They seem equally optimal, but very different.
>   Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>   srl+and is clearer.
>  I don't remember which of these worked.
> 
> 
> <     srl    %g1, 22, %g1
> 
> <     and    %g1, 1, %g1
> 
> ---
> 
>>     sll    %g1, 22, %g1
> 
>>     srl    %g1, 31, %g1
> 
> 
> 
> I read the first as:
>   extract bit 22, plus or minus 1
> vs.
>   extract bit 32-22=10, plus or minus 1.
> 
> 
> It would probably be ok to move bits around, but insert would have to match.
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Fri, 14 May 2010 22:13:58 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>> 
>>  - Jay
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>> 
>>> 
>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>> 
>>> 
>>> I have some extra time today, so, plan:
>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>> test undo just the bitfield insert/extract change, see if that is the problem
>>> work through the others if not
>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>> case if I put it back, no need for test coverage, probably nobody will ever
>>> touch it again, which is fine. :) )
>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>> if others are ruled out I'll undo or test it.
>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>> set changes. Only through experimentation/testing could I know that
>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>> it appeared to be a very convenient coincidence.)
>>> 
>>> 
>>> I am surprised that I386_* working and broken.
>>> I would think wordsize and endian is all that matters here.
>>> 
>>> 
>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> 
>>>> 
>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>> I agree if they drop it, we have to.
>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>> but that's not likely.
>>>> A C generating backend also solves this.
>>>> 
>>>> 
>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>> 
>>>> 
>>>> I don't remember about div/mod.
>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>> 
>>>> 
>>>> I'm also not optimizing at all.
>>>> 
>>>> 
>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>> easily, and I'm also not keen on the huge testing matrix.
>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>> 
>>>> 
>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>> 
>>>> 
>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> 
>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>> 
>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>> 
>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>> 
>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>> 
>>>>>> 
>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>> - my changes to set operations
>>>>>> - my change to div/mod
>>>>>> - Tony's to bit field operations
>>>>>> 
>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>> 
>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>> to keep them if they don't work.
>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> 
>>>>>>> 
>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>> 
>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>> (gdb) disassem
>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>> 
>>>>>>>> 
>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>> 
>>>>>>>> - Jay
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  

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

From hosking at cs.purdue.edu  Sat May 15 06:14:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 00:14:08 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>
Message-ID: <131F4BA5-0960-429D-B711-304FEE55A4F1@cs.purdue.edu>

It would be great if we could understand what is going on here, because as I recall the code looked to be correct, at least on x86.

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 14 May 2010, at 21:07, Jay K wrote:

> 
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
> 
> Er.
> first: a = (a>> 22) & 1;
> second: a = (a << 22)>> 31;
> 
> are actually darn close, maybe the same.
> Let's just be lame and test in C:
> 
> #include <stdio.h>
> int main()
> {
> unsigned a = ~0;
> unsigned b = (a>> 22) & 1;
> unsigned c = (a << 22)>> 31;
> printf("%x %x\n", b, c);
> return 0;
> }
> 
> both print 1. So I remain a bit uncertain.
> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
> I might dig more before commiting the undo.
> Maybe bit fields of multiple bits are the only ones broken.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 00:24:03 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> Tony I think it is your change to extract_mn.
>> Try it with SOLsun for example.
>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>> 
>> 
>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>> 77,78c77,78
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
>> 118,119c118,119
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
>> 197,198c197,198
>> <     srl    %g1, 21, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 21, %g1
>>>    srl    %g1, 31, %g1
>> 236,237c236,237
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> ---
>>>    sll    %g1, 22, %g1
>>>    srl    %g1, 31, %g1
>> 273,274c273,274
>> <     srl    %g1, 22, %g1
>> <     and    %g1, 1, %g1
>> 
>> 
>> This is not optimized.
>> They seem equally optimal, but very different.
>>  Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>  srl+and is clearer.
>> I don't remember which of these worked.
>> 
>> 
>> <     srl    %g1, 22, %g1
>> 
>> <     and    %g1, 1, %g1
>> 
>> ---
>> 
>>>    sll    %g1, 22, %g1
>> 
>>>    srl    %g1, 31, %g1
>> 
>> 
>> 
>> I read the first as:
>>  extract bit 22, plus or minus 1
>> vs.
>>  extract bit 32-22=10, plus or minus 1.
>> 
>> 
>> It would probably be ok to move bits around, but insert would have to match.
>> 
>> 
>> - Jay
>> 
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> 
>>> 
>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>> 
>>>> 
>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>> 
>>>> 
>>>> I have some extra time today, so, plan:
>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>> work through the others if not
>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>> touch it again, which is fine. :) )
>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>> if others are ruled out I'll undo or test it.
>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>> set changes. Only through experimentation/testing could I know that
>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>> it appeared to be a very convenient coincidence.)
>>>> 
>>>> 
>>>> I am surprised that I386_* working and broken.
>>>> I would think wordsize and endian is all that matters here.
>>>> 
>>>> 
>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> 
>>>>> 
>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>> I agree if they drop it, we have to.
>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>> but that's not likely.
>>>>> A C generating backend also solves this.
>>>>> 
>>>>> 
>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>> 
>>>>> 
>>>>> I don't remember about div/mod.
>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>> 
>>>>> 
>>>>> I'm also not optimizing at all.
>>>>> 
>>>>> 
>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>> 
>>>>> 
>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>> 
>>>>> 
>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>> 
>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>> 
>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>> 
>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>> 
>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>> 
>>>>>>> 
>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>> - my changes to set operations
>>>>>>> - my change to div/mod
>>>>>>> - Tony's to bit field operations
>>>>>>> 
>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>> 
>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>> to keep them if they don't work.
>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>> 
>>>>>>>> - Jay
>>>>>>>> 
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>> 
>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>> (gdb) disassem
>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>> 
>>>>>>>>> - Jay
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  

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

From hosking at cs.purdue.edu  Sat May 15 06:14:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 00:14:54 -0400
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>
Message-ID: <558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>

COMPONENT_REF is difficult because of the lack of type info I think.  Please revert to what it used to be.


On 14 May 2010, at 23:10, Jay K wrote:

> 
> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
> 
> BIT_FIELD_REF considered harmful
> 
> We should try to use COMPONENT_REF instead.
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 01:29:01 +0000
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>> 
>> 
>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>> A more accurate one, which shows a problem, is:
>> 
>> #include 
>> 
>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>> 
>> int main()
>> {
>>    unsigned a = 1 << 22;
>>    printf("%x %x\n", F1(a), F2(a));
>>    return 0;
>> }
>> 
>> But I'm still having trouble convincing myself.
>> I guess the second might give you the 10th bit.
>> Er, the 9th.
>> 
>> #include 
>> 
>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>> 
>> int main()
>> {
>>    unsigned a = 1 << 22;
>>    printf("%x %x\n", F1(a), F2(a));
>> 
>>    a = 1 << 9;
>>    printf("%x %x\n", F1(a), F2(a));
>>    return 0;
>> }
>> 
>> 1 0
>> 0 1
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>> 
>>> 
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>> 
>>> Er.
>>> first: a = (a>> 22) & 1;
>>> second: a = (a << 22)>> 31;
>>> 
>>> are actually darn close, maybe the same.
>>> Let's just be lame and test in C:
>>> 
>>> #include
>>> int main()
>>> {
>>> unsigned a = ~0;
>>> unsigned b = (a>> 22) & 1;
>>> unsigned c = (a << 22)>> 31;
>>> printf("%x %x\n", b, c);
>>> return 0;
>>> }
>>> 
>>> both print 1. So I remain a bit uncertain.
>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>> I might dig more before commiting the undo.
>>> Maybe bit fields of multiple bits are the only ones broken.
>>> 
>>> - Jay
>>> 
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>> 
>>>> 
>>>> Tony I think it is your change to extract_mn.
>>>> Try it with SOLsun for example.
>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>> 
>>>> 
>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>> 77,78c77,78
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>>> 118,119c118,119
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>>> 197,198c197,198
>>>> < srl %g1, 21, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 21, %g1
>>>>> srl %g1, 31, %g1
>>>> 236,237c236,237
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> ---
>>>>> sll %g1, 22, %g1
>>>>> srl %g1, 31, %g1
>>>> 273,274c273,274
>>>> < srl %g1, 22, %g1
>>>> < and %g1, 1, %g1
>>>> 
>>>> 
>>>> This is not optimized.
>>>> They seem equally optimal, but very different.
>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>> srl+and is clearer.
>>>> I don't remember which of these worked.
>>>> 
>>>> 
>>>> < srl %g1, 22, %g1
>>>> 
>>>> < and %g1, 1, %g1
>>>> 
>>>> ---
>>>> 
>>>>> sll %g1, 22, %g1
>>>> 
>>>>> srl %g1, 31, %g1
>>>> 
>>>> 
>>>> 
>>>> I read the first as:
>>>> extract bit 22, plus or minus 1
>>>> vs.
>>>> extract bit 32-22=10, plus or minus 1.
>>>> 
>>>> 
>>>> It would probably be ok to move bits around, but insert would have to match.
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>> 
>>>>> 
>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>> 
>>>>>> 
>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>> 
>>>>>> 
>>>>>> I have some extra time today, so, plan:
>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>> work through the others if not
>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>> touch it again, which is fine. :) )
>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>> if others are ruled out I'll undo or test it.
>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>> it appeared to be a very convenient coincidence.)
>>>>>> 
>>>>>> 
>>>>>> I am surprised that I386_* working and broken.
>>>>>> I would think wordsize and endian is all that matters here.
>>>>>> 
>>>>>> 
>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> 
>>>>>>> 
>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>> I agree if they drop it, we have to.
>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>> but that's not likely.
>>>>>>> A C generating backend also solves this.
>>>>>>> 
>>>>>>> 
>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>> 
>>>>>>> 
>>>>>>> I don't remember about div/mod.
>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>> 
>>>>>>> 
>>>>>>> I'm also not optimizing at all.
>>>>>>> 
>>>>>>> 
>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>> 
>>>>>>> 
>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>> 
>>>>>>> 
>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>> 
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> 
>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>> 
>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>> 
>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>> 
>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>> - my changes to set operations
>>>>>>>>> - my change to div/mod
>>>>>>>>> - Tony's to bit field operations
>>>>>>>>> 
>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>> 
>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>> to keep them if they don't work.
>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>> 
>>>>>>>>> - Jay
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>> 
>>>>>>>>>> - Jay
>>>>>>>>>> 
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>> 
>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>> 
>>>>>>>>>>> - Jay
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Sat May 15 07:57:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 05:57:27 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , ,
	,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , ,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , ,
	,,<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, ,
	,,<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>,
	, , <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
Message-ID: <COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>


I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
And that bit offsets are interpreted differently for big endian and little endian.
? I can NOT confirm that I386_LINUX was broken.
? As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.


I happen to then try a bunch of big endian platforms.


Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
but I think it is fairly easy to come up with structs without bitfields with the "same" layout
across all architectures, at least for a given wordsize/endian.)


I should admit something.
When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
Lately for this reason I've been removing them from code where I can.
Clearly they have a place, where compactness of data is of the prime importance.


It's possible this is just me, that more expert programmers can readily imagine just how
bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
therefore they can determine the layout from glancing at the declaration.


I just can't imagine what would be obvious.
Simple example:

typedef union {
? unsigned AsInt32;
? struct { unsigned a : 1 } Bits;
} T1;


T1 t;
t.Bits.a = 1;


printf("%x\n", t.AsInt32);


prints 1 or 0x80000000 or what?


It could be there are obvious rules, and they are endian dependent, but that otherwise
all ABIs and compilers define them the same.
If that is the case, I think we could get something more "optimal".
However, notice how similar the "optimized" code was.
And we could easily generate that without a bitfield ref.
?Just shift right and and with a constant, instead of shift left and then right.


Could be that the decision is target-dependent as to what is optimal though.


?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:14:54 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>
>
> On 14 May 2010, at 23:10, Jay K wrote:
>
>>
>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>
>> BIT_FIELD_REF considered harmful
>>
>> We should try to use COMPONENT_REF instead.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>> A more accurate one, which shows a problem, is:
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> But I'm still having trouble convincing myself.
>>> I guess the second might give you the 10th bit.
>>> Er, the 9th.
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>>
>>> a = 1 << 9;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> 1 0
>>> 0 1
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>
>>>> Er.
>>>> first: a = (a>> 22) & 1;
>>>> second: a = (a << 22)>> 31;
>>>>
>>>> are actually darn close, maybe the same.
>>>> Let's just be lame and test in C:
>>>>
>>>> #include
>>>> int main()
>>>> {
>>>> unsigned a = ~0;
>>>> unsigned b = (a>> 22) & 1;
>>>> unsigned c = (a << 22)>> 31;
>>>> printf("%x %x\n", b, c);
>>>> return 0;
>>>> }
>>>>
>>>> both print 1. So I remain a bit uncertain.
>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>> I might dig more before commiting the undo.
>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Tony I think it is your change to extract_mn.
>>>>> Try it with SOLsun for example.
>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>
>>>>>
>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>> 77,78c77,78
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 118,119c118,119
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 197,198c197,198
>>>>> < srl %g1, 21, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 21, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 236,237c236,237
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 273,274c273,274
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>>
>>>>>
>>>>> This is not optimized.
>>>>> They seem equally optimal, but very different.
>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>> srl+and is clearer.
>>>>> I don't remember which of these worked.
>>>>>
>>>>>
>>>>> < srl %g1, 22, %g1
>>>>>
>>>>> < and %g1, 1, %g1
>>>>>
>>>>> ---
>>>>>
>>>>>> sll %g1, 22, %g1
>>>>>
>>>>>> srl %g1, 31, %g1
>>>>>
>>>>>
>>>>>
>>>>> I read the first as:
>>>>> extract bit 22, plus or minus 1
>>>>> vs.
>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>
>>>>>
>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>
>>>>>>>
>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>
>>>>>>>
>>>>>>> I have some extra time today, so, plan:
>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>> work through the others if not
>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>> touch it again, which is fine. :) )
>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>
>>>>>>>
>>>>>>> I am surprised that I386_* working and broken.
>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>
>>>>>>>
>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>> I agree if they drop it, we have to.
>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>> but that's not likely.
>>>>>>>> A C generating backend also solves this.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't remember about div/mod.
>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm also not optimizing at all.
>>>>>>>>
>>>>>>>>
>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>
>>>>>>>>
>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>
>>>>>>>>
>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>
>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>
>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>
>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>> - my changes to set operations
>>>>>>>>>> - my change to div/mod
>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>
>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>
>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 07:58:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 05:58:57 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
	SPARC64_SOLARIS)
In-Reply-To: <558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , ,
	,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , ,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , ,
	,,<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, ,
	,,<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>,
	, , <COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
Message-ID: <COL101-W188664168A5CE39254D0F5E6FE0@phx.gbl>


> COMPONENT_REF is difficult because of the lack of type info I think
That's what I thought.
It's unfortunate imho.
We could probably do better fairly easily. ?
? Heck, with the possible major upside of having gdb work? (I don't mean m3gdb).
I'm still bothered by the problem I had on OpenBSD/mips64 where a "bitfield ref" with a high byte offset
was treated incorrectly by the compiler, where a component ref would surely have worked.

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 00:14:54 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>
>
> On 14 May 2010, at 23:10, Jay K wrote:
>
>>
>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>
>> BIT_FIELD_REF considered harmful
>>
>> We should try to use COMPONENT_REF instead.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>>
>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>> A more accurate one, which shows a problem, is:
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> But I'm still having trouble convincing myself.
>>> I guess the second might give you the 10th bit.
>>> Er, the 9th.
>>>
>>> #include
>>>
>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>
>>> int main()
>>> {
>>> unsigned a = 1 << 22;
>>> printf("%x %x\n", F1(a), F2(a));
>>>
>>> a = 1 << 9;
>>> printf("%x %x\n", F1(a), F2(a));
>>> return 0;
>>> }
>>>
>>> 1 0
>>> 0 1
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>
>>>> Er.
>>>> first: a = (a>> 22) & 1;
>>>> second: a = (a << 22)>> 31;
>>>>
>>>> are actually darn close, maybe the same.
>>>> Let's just be lame and test in C:
>>>>
>>>> #include
>>>> int main()
>>>> {
>>>> unsigned a = ~0;
>>>> unsigned b = (a>> 22) & 1;
>>>> unsigned c = (a << 22)>> 31;
>>>> printf("%x %x\n", b, c);
>>>> return 0;
>>>> }
>>>>
>>>> both print 1. So I remain a bit uncertain.
>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>> I might dig more before commiting the undo.
>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Tony I think it is your change to extract_mn.
>>>>> Try it with SOLsun for example.
>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>
>>>>>
>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>> 77,78c77,78
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 118,119c118,119
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 197,198c197,198
>>>>> < srl %g1, 21, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 21, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 236,237c236,237
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>> ---
>>>>>> sll %g1, 22, %g1
>>>>>> srl %g1, 31, %g1
>>>>> 273,274c273,274
>>>>> < srl %g1, 22, %g1
>>>>> < and %g1, 1, %g1
>>>>>
>>>>>
>>>>> This is not optimized.
>>>>> They seem equally optimal, but very different.
>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>> srl+and is clearer.
>>>>> I don't remember which of these worked.
>>>>>
>>>>>
>>>>> < srl %g1, 22, %g1
>>>>>
>>>>> < and %g1, 1, %g1
>>>>>
>>>>> ---
>>>>>
>>>>>> sll %g1, 22, %g1
>>>>>
>>>>>> srl %g1, 31, %g1
>>>>>
>>>>>
>>>>>
>>>>> I read the first as:
>>>>> extract bit 22, plus or minus 1
>>>>> vs.
>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>
>>>>>
>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>
>>>>>>>
>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>
>>>>>>>
>>>>>>> I have some extra time today, so, plan:
>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>> work through the others if not
>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>> touch it again, which is fine. :) )
>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>
>>>>>>>
>>>>>>> I am surprised that I386_* working and broken.
>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>
>>>>>>>
>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>> I agree if they drop it, we have to.
>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>> but that's not likely.
>>>>>>>> A C generating backend also solves this.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't remember about div/mod.
>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm also not optimizing at all.
>>>>>>>>
>>>>>>>>
>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>
>>>>>>>>
>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>
>>>>>>>>
>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>
>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>
>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>
>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>> - my changes to set operations
>>>>>>>>>> - my change to div/mod
>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>
>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>
>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 09:03:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 07:03:53 +0000
Subject: [M3devel] random.longint()?
Message-ID: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>


In libm3 there is random number generation.
In libm3 that is code that wants 8 random bytes.
? If integer is 4 bytes, it calls random.integer() twice, else if it is 8, once.

It seems natural that we should provide random.longint()?

And then the other code can just use it?

Someone can look into the random number generator and
?- make sure it is actually "correct" for 64bit integer?
?- and if so, change the lowest level to use LONGINT
?? and layer integer over it? -- not sure how, presumably
?? taking only the lower 32bits loses too much randomness?


This is what I get for looking into why we are ever asked to extract 0 bits..

"Everywhere I look, I see bugs." (topic of a separate mail)

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Sat May 15 09:08:03 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 07:08:03 +0000
Subject: [M3devel] libm3/Swap?
Message-ID: <COL101-W58DAAF4635345A955820B5E6FE0@phx.gbl>


libm3/.../swap.m3:


FROM Word IMPORT Or, And, Not, LeftShift, RightShift, Extract;


CONST
? B0 = 16_FF;
? B1 = 16_FF00;
? B2 = 16_FF0000;
? B3 = 16_FF000000;


? (* These will all be zero on machines with BYTESIZE(INTEGER) = 32 *)
? B4 = LeftShift(B3, 8);
? B5 = LeftShift(B4, 8);
? B6 = LeftShift(B5, 8);
? B7 = LeftShift(B6, 8);

CONST SignExt32 = ARRAY [0..1] OF Word.T {0, Not(16_FFFFFFFF)};

(* Swaps the lower 4 bytes of i *)
PROCEDURE Swap4 (i: Int32): Int32 =
? BEGIN
??? IF BYTESIZE(INTEGER) = 4 THEN
????? RETURN Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
??????????????? Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24)));
??? ELSIF BYTESIZE(INTEGER) = 8 THEN
????? RETURN
??????? Or(SignExt32[Extract(i, 7, 1)],
?????????? Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
????????????? Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24))));
??? ELSE
????? RAISE Failure;
??? END;
? END Swap4;


What is the meaning of the 7?
? In Extract(i, 7, 1)?
Presumably it should be 63??
I guess I'll write a test..


Is there a better idiom that doesn't expose? architectures to compile code for other word sizes?
Maybe fork the file and include_dir(WORD_SIZE)?
?Like is done in m3core/src/C?
?

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sat May 15 11:24:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 09:24:02 +0000
Subject: [M3devel] libm3/Swap?
Message-ID: <COL101-W64EAAFCE37D8755D457662E6FE0@phx.gbl>


Oh I see, it is sign extending the result, not copying the sign from the original.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: libm3/Swap?
> Date: Sat, 15 May 2010 07:08:03 +0000
>
>
> libm3/.../swap.m3:
>
>
> FROM Word IMPORT Or, And, Not, LeftShift, RightShift, Extract;
>
>
> CONST
>   B0 = 16_FF;
>   B1 = 16_FF00;
>   B2 = 16_FF0000;
>   B3 = 16_FF000000;
>
>
>   (* These will all be zero on machines with BYTESIZE(INTEGER) = 32 *)
>   B4 = LeftShift(B3, 8);
>   B5 = LeftShift(B4, 8);
>   B6 = LeftShift(B5, 8);
>   B7 = LeftShift(B6, 8);
>
> CONST SignExt32 = ARRAY [0..1] OF Word.T {0, Not(16_FFFFFFFF)};
>
> (* Swaps the lower 4 bytes of i *)
> PROCEDURE Swap4 (i: Int32): Int32 =
>   BEGIN
>     IF BYTESIZE(INTEGER) = 4 THEN
>       RETURN Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
>                 Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24)));
>     ELSIF BYTESIZE(INTEGER) = 8 THEN
>       RETURN
>         Or(SignExt32[Extract(i, 7, 1)],
>            Or(Or(RightShift(And(B3, i), 24), RightShift(And(B2, i), 8)),
>               Or(LeftShift(And(B1, i), 8), LeftShift(And(B0, i), 24))));
>     ELSE
>       RAISE Failure;
>     END;
>   END Swap4;
>
>
> What is the meaning of the 7?
>   In Extract(i, 7, 1)?
> Presumably it should be 63??
> I guess I'll write a test..
>
>
> Is there a better idiom that doesn't expose  architectures to compile code for other word sizes?
> Maybe fork the file and include_dir(WORD_SIZE)?
>  Like is done in m3core/src/C?
>
>
>  - Jay
>
 		 	   		  

From hosking at cs.purdue.edu  Sat May 15 18:36:25 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 15 May 2010 12:36:25 -0400
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>
Message-ID: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>

I hesitate to slow down the default implementation of random by using LONGINT (slow) instead of INTEGER (fast).

On 15 May 2010, at 03:03, Jay K wrote:

> 
> In libm3 there is random number generation.
> In libm3 that is code that wants 8 random bytes.
>   If integer is 4 bytes, it calls random.integer() twice, else if it is 8, once.
> 
> It seems natural that we should provide random.longint()?
> 
> And then the other code can just use it?
> 
> Someone can look into the random number generator and
>  - make sure it is actually "correct" for 64bit integer?
>  - and if so, change the lowest level to use LONGINT
>    and layer integer over it? -- not sure how, presumably
>    taking only the lower 32bits loses too much randomness?
> 
> 
> This is what I get for looking into why we are ever asked to extract 0 bits..
> 
> "Everywhere I look, I see bugs." (topic of a separate mail)
> 
>  - Jay
> 
> 		 	   		  



From jay.krell at cornell.edu  Sun May 16 01:22:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 15 May 2010 23:22:42 +0000
Subject: [M3devel] random.longint()?
In-Reply-To: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>,
	<DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
Message-ID: <COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>


Fair enough. I guess random.longint() could just call random.integer() twice, or clients could, existing situation, do nothing.

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 15 May 2010 12:36:25 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] random.longint()?
>
> I hesitate to slow down the default implementation of random by using LONGINT (slow) instead of INTEGER (fast).
>
> On 15 May 2010, at 03:03, Jay K wrote:
>
>>
>> In libm3 there is random number generation.
>> In libm3 that is code that wants 8 random bytes.
>> If integer is 4 bytes, it calls random.integer() twice, else if it is 8, once.
>>
>> It seems natural that we should provide random.longint()?
>>
>> And then the other code can just use it?
>>
>> Someone can look into the random number generator and
>> - make sure it is actually "correct" for 64bit integer?
>> - and if so, change the lowest level to use LONGINT
>> and layer integer over it? -- not sure how, presumably
>> taking only the lower 32bits loses too much randomness?
>>
>>
>> This is what I get for looking into why we are ever asked to extract 0 bits..
>>
>> "Everywhere I look, I see bugs." (topic of a separate mail)
>>
>> - Jay
>>
>>
>
 		 	   		  

From rodney_bates at lcwb.coop  Sun May 16 03:59:18 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 15 May 2010 20:59:18 -0500
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
 SPARC64_SOLARIS)
In-Reply-To: <COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , , ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , , ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, , ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>
	<COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>
Message-ID: <4BEF5176.5020503@lcwb.coop>



Jay K wrote:
> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
> And that bit offsets are interpreted differently for big endian and little endian.
>   I can NOT confirm that I386_LINUX was broken.
>   As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
> 
> 
> I happen to then try a bunch of big endian platforms.
> 
> 
> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
> across all architectures, at least for a given wordsize/endian.)
> 
> 
> I should admit something.
> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
> Lately for this reason I've been removing them from code where I can.
> Clearly they have a place, where compactness of data is of the prime importance.
> 
> 
> It's possible this is just me, that more expert programmers can readily imagine just how
> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
> therefore they can determine the layout from glancing at the declaration.
> 

According to my C '99 standard, just about everything about bit field layout is
implementation-defined, except for the bit count of each field.  Harbison and
Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
using bit-twiddling operators instead of bit fields.  Failing that, they recommend
doing experiments with your particular compiler to verify your assumptions.  Obviously
not possible for portable code.

They do suggest that the fields will likely be laid out right-to-left on a little-endian
machine and conversely.  But even there, it matters what size of "unit" is laid out
this way (a native word, for example) before moving on to the next unit, and that
is also implementation-defined.


> 
> I just can't imagine what would be obvious.
> Simple example:
> 
> typedef union {
>   unsigned AsInt32;
>   struct { unsigned a : 1 } Bits;
> } T1;
> 
> 
> T1 t;
> t.Bits.a = 1;
> 
> 
> printf("%x\n", t.AsInt32);
> 
> 
> prints 1 or 0x80000000 or what?
> 
> 
> It could be there are obvious rules, and they are endian dependent, but that otherwise
> all ABIs and compilers define them the same.
> If that is the case, I think we could get something more "optimal".
> However, notice how similar the "optimized" code was.
> And we could easily generate that without a bitfield ref.
>  Just shift right and and with a constant, instead of shift left and then right.
> 
> 
> Could be that the decision is target-dependent as to what is optimal though.
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Sat, 15 May 2010 00:14:54 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>
>>
>> On 14 May 2010, at 23:10, Jay K wrote:
>>
>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>
>>> BIT_FIELD_REF considered harmful
>>>
>>> We should try to use COMPONENT_REF instead.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>>
>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>> A more accurate one, which shows a problem, is:
>>>>
>>>> #include
>>>>
>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>
>>>> int main()
>>>> {
>>>> unsigned a = 1 << 22;
>>>> printf("%x %x\n", F1(a), F2(a));
>>>> return 0;
>>>> }
>>>>
>>>> But I'm still having trouble convincing myself.
>>>> I guess the second might give you the 10th bit.
>>>> Er, the 9th.
>>>>
>>>> #include
>>>>
>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>
>>>> int main()
>>>> {
>>>> unsigned a = 1 << 22;
>>>> printf("%x %x\n", F1(a), F2(a));
>>>>
>>>> a = 1 << 9;
>>>> printf("%x %x\n", F1(a), F2(a));
>>>> return 0;
>>>> }
>>>>
>>>> 1 0
>>>> 0 1
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>> Er.
>>>>> first: a = (a>> 22) & 1;
>>>>> second: a = (a << 22)>> 31;
>>>>>
>>>>> are actually darn close, maybe the same.
>>>>> Let's just be lame and test in C:
>>>>>
>>>>> #include
>>>>> int main()
>>>>> {
>>>>> unsigned a = ~0;
>>>>> unsigned b = (a>> 22) & 1;
>>>>> unsigned c = (a << 22)>> 31;
>>>>> printf("%x %x\n", b, c);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> both print 1. So I remain a bit uncertain.
>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>> I might dig more before commiting the undo.
>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Tony I think it is your change to extract_mn.
>>>>>> Try it with SOLsun for example.
>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>
>>>>>>
>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>> 77,78c77,78
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 118,119c118,119
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 197,198c197,198
>>>>>> < srl %g1, 21, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 21, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 236,237c236,237
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>> ---
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>> 273,274c273,274
>>>>>> < srl %g1, 22, %g1
>>>>>> < and %g1, 1, %g1
>>>>>>
>>>>>>
>>>>>> This is not optimized.
>>>>>> They seem equally optimal, but very different.
>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>> srl+and is clearer.
>>>>>> I don't remember which of these worked.
>>>>>>
>>>>>>
>>>>>> < srl %g1, 22, %g1
>>>>>>
>>>>>> < and %g1, 1, %g1
>>>>>>
>>>>>> ---
>>>>>>
>>>>>>> sll %g1, 22, %g1
>>>>>>> srl %g1, 31, %g1
>>>>>>
>>>>>>
>>>>>> I read the first as:
>>>>>> extract bit 22, plus or minus 1
>>>>>> vs.
>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>
>>>>>>
>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>
>>>>>>>>
>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>
>>>>>>>>
>>>>>>>> I have some extra time today, so, plan:
>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>> work through the others if not
>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>> touch it again, which is fine. :) )
>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>
>>>>>>>>
>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>
>>>>>>>>
>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>> but that's not likely.
>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't remember about div/mod.
>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>
>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>
>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>
>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>
>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>
>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>
>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>
>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>
>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>  		 	   		  


From hendrik at topoi.pooq.com  Sun May 16 01:05:51 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 15 May 2010 19:05:51 -0400
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
References: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
	<COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
Message-ID: <20100515230551.GA24444@topoi.pooq.com>

On Sat, May 15, 2010 at 11:22:42PM +0000, Jay K wrote:
> 
> Fair enough. I guess random.longint() could just call random.integer() twice, or clients could, existing situation, do nothing.

Just how many bits of state does the random number generator have?

-- hendrik


From jay.krell at cornell.edu  Sun May 16 06:36:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 16 May 2010 04:36:21 +0000
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
 SPARC64_SOLARIS)
In-Reply-To: <4BEF5176.5020503@lcwb.coop>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , ,
	,,<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , ,
	,,<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , ,
	,,<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , ,
	,,<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , ,
	,,<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , ,
	,,<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, ,
	,,<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>,
	, , <COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>, ,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>, ,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>,
	<COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>,
	<4BEF5176.5020503@lcwb.coop>
Message-ID: <COL101-W228E73F7491802AFD3D41AE6FF0@phx.gbl>


> They do suggest that the fields will likely be laid out right-to-left
> on a little-endian machine and conversely.  But even there, it matters
> what size of "unit" is laid out this way (a native word, for example)
> before moving on to the next unit, and that is also implementation-defined.
 
This is what I was alluding to.
Even though the rules are explicitly compiler-dependent, it could be
that to all compiler writers, such as their shared mindset may be,
there are fairly obvious rules to adopt
and they pretty much all adopt the same ones. I don't know.

Not "all compilers", but "gcc on all platforms".

I suspect that if we said like:
#if TARGET_BIG_ENDIAN /* or !TARGET_LITTLE_ENDIAN, one of these probably exists */
  m = TYPE_PRECISION(t) - m.
#endif

it'd work.


Anyway, I put the code back.


It would also be a good idea to consistently used bitfields for all insert/extract
forms, instead of just one extract form. That would provide consistency.
But we also use extract in other places, e.g. division.
 So consistency between insert and extract isn't actually sufficient.


We do use bitfields in an odd way -- for all loads and stores,
that either have a non-zero offset or that do a type conversion,
and it bugs me.


There is something in gcc that decides if you are offseting
more than a word into something only a word size, throw out the offset,
or somesuch. OpenBSD/mips64 used to incorrectly access all "globals".
"Globals" are defined by parse.c as just a block of memory
with a name for its start, and..we don't know the size, so before
we said it is arbitrarily small, like a word, as a workaround I
declare that it is a arbitrarily less small:


static void
m3cg_declare_segment (void)
{
...
  /* we really don't have an idea of what the type of this var is; let's try
     to put something that will be good enough for all the uses of this var we
     are going to see before we have a bind_segment. Use a large size so that
     gcc doesn't think it fits in a register, so that loads out of it do get
     their offsets applied. */
  TREE_TYPE (v)
    = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);
  layout_decl (v, BIGGEST_ALIGNMENT);


We do actually know the size though.
The thing could be declared to be a record with typed fields
 and we could use "component refs", except we don't bother
 passing enough information along.
It's related to what Tony and I said yesterday.


(OpenBSD/mips64 isn't known to fully work anyway.
But MIPS is making a comeback, see:
http://www.openbsd.org/loongson.html
http://www.lemote.com/en/products/all-in-one/2010/0311/122.html
http://www.lemote.com/en/products/Notebook/2010/0310/112.html
etc.
)

?- Jay

----------------------------------------
> Date: Sat, 15 May 2010 20:59:18 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>
>
>
> Jay K wrote:
>> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
>> And that bit offsets are interpreted differently for big endian and little endian.
>> I can NOT confirm that I386_LINUX was broken.
>> As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
>>
>>
>> I happen to then try a bunch of big endian platforms.
>>
>>
>> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
>> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
>> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
>> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
>> across all architectures, at least for a given wordsize/endian.)
>>
>>
>> I should admit something.
>> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
>> Lately for this reason I've been removing them from code where I can.
>> Clearly they have a place, where compactness of data is of the prime importance.
>>
>>
>> It's possible this is just me, that more expert programmers can readily imagine just how
>> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
>> therefore they can determine the layout from glancing at the declaration.
>>
>
> According to my C '99 standard, just about everything about bit field layout is
> implementation-defined, except for the bit count of each field. Harbison and
> Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
> using bit-twiddling operators instead of bit fields. Failing that, they recommend
> doing experiments with your particular compiler to verify your assumptions. Obviously
> not possible for portable code.
>
> They do suggest that the fields will likely be laid out right-to-left on a little-endian
> machine and conversely. But even there, it matters what size of "unit" is laid out
> this way (a native word, for example) before moving on to the next unit, and that
> is also implementation-defined.
>
>
>>
>> I just can't imagine what would be obvious.
>> Simple example:
>>
>> typedef union {
>> unsigned AsInt32;
>> struct { unsigned a : 1 } Bits;
>> } T1;
>>
>>
>> T1 t;
>> t.Bits.a = 1;
>>
>>
>> printf("%x\n", t.AsInt32);
>>
>>
>> prints 1 or 0x80000000 or what?
>>
>>
>> It could be there are obvious rules, and they are endian dependent, but that otherwise
>> all ABIs and compilers define them the same.
>> If that is the case, I think we could get something more "optimal".
>> However, notice how similar the "optimized" code was.
>> And we could easily generate that without a bitfield ref.
>> Just shift right and and with a constant, instead of shift left and then right.
>>
>>
>> Could be that the decision is target-dependent as to what is optimal though.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Sat, 15 May 2010 00:14:54 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>
>>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>>
>>>
>>> On 14 May 2010, at 23:10, Jay K wrote:
>>>
>>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>>
>>>> BIT_FIELD_REF considered harmful
>>>>
>>>> We should try to use COMPONENT_REF instead.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu
>>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>
>>>>>
>>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>>> A more accurate one, which shows a problem, is:
>>>>>
>>>>> #include
>>>>>
>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>
>>>>> int main()
>>>>> {
>>>>> unsigned a = 1 << 22;
>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>> return 0;
>>>>> }
>>>>>
>>>>> But I'm still having trouble convincing myself.
>>>>> I guess the second might give you the 10th bit.
>>>>> Er, the 9th.
>>>>>
>>>>> #include
>>>>>
>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>
>>>>> int main()
>>>>> {
>>>>> unsigned a = 1 << 22;
>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>
>>>>> a = 1 << 9;
>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>> return 0;
>>>>> }
>>>>>
>>>>> 1 0
>>>>> 0 1
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>> Er.
>>>>>> first: a = (a>> 22) & 1;
>>>>>> second: a = (a << 22)>> 31;
>>>>>>
>>>>>> are actually darn close, maybe the same.
>>>>>> Let's just be lame and test in C:
>>>>>>
>>>>>> #include
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = ~0;
>>>>>> unsigned b = (a>> 22) & 1;
>>>>>> unsigned c = (a << 22)>> 31;
>>>>>> printf("%x %x\n", b, c);
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> both print 1. So I remain a bit uncertain.
>>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>>> I might dig more before commiting the undo.
>>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>> Tony I think it is your change to extract_mn.
>>>>>>> Try it with SOLsun for example.
>>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>>
>>>>>>>
>>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>>> 77,78c77,78
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 118,119c118,119
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 197,198c197,198
>>>>>>> < srl %g1, 21, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 21, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 236,237c236,237
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>> ---
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>> 273,274c273,274
>>>>>>> < srl %g1, 22, %g1
>>>>>>> < and %g1, 1, %g1
>>>>>>>
>>>>>>>
>>>>>>> This is not optimized.
>>>>>>> They seem equally optimal, but very different.
>>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>>> srl+and is clearer.
>>>>>>> I don't remember which of these worked.
>>>>>>>
>>>>>>>
>>>>>>> < srl %g1, 22, %g1
>>>>>>>
>>>>>>> < and %g1, 1, %g1
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>>> sll %g1, 22, %g1
>>>>>>>> srl %g1, 31, %g1
>>>>>>>
>>>>>>>
>>>>>>> I read the first as:
>>>>>>> extract bit 22, plus or minus 1
>>>>>>> vs.
>>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>>
>>>>>>>
>>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have some extra time today, so, plan:
>>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>>> work through the others if not
>>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>>> touch it again, which is fine. :) )
>>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>>> but that's not likely.
>>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't remember about div/mod.
>>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>>
>>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>>
>>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>>
>>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>>
>>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>>
>>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>>
>>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>>
>>>>>>>>>>>> - Jay
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>
 		 	   		  

From rodney_bates at lcwb.coop  Sun May 16 19:53:13 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 16 May 2010 12:53:13 -0500
Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD,
 SPARC64_SOLARIS)
In-Reply-To: <COL101-W228E73F7491802AFD3D41AE6FF0@phx.gbl>
References: <COL101-W391A5C151DF066736100D6E6FD0@phx.gbl>, , , , , , , , , ,
	<COL101-W54F21DE14C2005A4A36B74E6FD0@phx.gbl>, , , , , , , ,
	<COL101-W594DEF6778F8293AA89C1CE6FD0@phx.gbl>, , , , , , , ,
	<01377FB9-321C-4F03-8B48-D2CE92C47949@cs.purdue.edu>, , , , , , ,
	<COL101-W31BB4BCE854A3FF6F17F9DE6FD0@phx.gbl>, , , , , ,
	<COL101-W3749FFBEED4E0083479C12E6FD0@phx.gbl>, , , , ,
	<COL101-W42FD8697991D5728E3DE4EE6FE0@phx.gbl>, , , ,
	<COL101-W13E5ADB5C65208D767D38EE6FE0@phx.gbl>, , ,
	<COL101-W35ACAC4082D2885BE1704AE6FE0@phx.gbl>, ,
	<COL101-W2413CE124BC7CE5D799D62E6FE0@phx.gbl>, ,
	<558B8CFC-6966-498B-9B3A-78BA5825918B@cs.purdue.edu>,
	<COL101-W354AFD5471F8580879546CE6FE0@phx.gbl>,
	<4BEF5176.5020503@lcwb.coop>
	<COL101-W228E73F7491802AFD3D41AE6FF0@phx.gbl>
Message-ID: <4BF03109.1050704@lcwb.coop>



Jay K wrote:
>> They do suggest that the fields will likely be laid out right-to-left
>> on a little-endian machine and conversely.  But even there, it matters
>> what size of "unit" is laid out this way (a native word, for example)
>> before moving on to the next unit, and that is also implementation-defined.
>  
> This is what I was alluding to.
> Even though the rules are explicitly compiler-dependent, it could be
> that to all compiler writers, such as their shared mindset may be,
> there are fairly obvious rules to adopt
> and they pretty much all adopt the same ones. I don't know.
> 
> Not "all compilers", but "gcc on all platforms".
> 
> I suspect that if we said like:
> #if TARGET_BIG_ENDIAN /* or !TARGET_LITTLE_ENDIAN, one of these probably exists */
>   m = TYPE_PRECISION(t) - m.
> #endif
> 
> it'd work.
> 
> 
> Anyway, I put the code back.
> 
> 
> It would also be a good idea to consistently used bitfields for all insert/extract
> forms, instead of just one extract form. That would provide consistency.
> But we also use extract in other places, e.g. division.
>  So consistency between insert and extract isn't actually sufficient.

Ah, are you talking about bit field _operators_ in the intermediate form
generated by parse.c to gcc?  These could well be a different animal
from C source code bit fields.  Or perhaps the C front end does a direct
translation, but gcc has well-defined semantics for them.  I would expect
these would follow a consistent pattern, for gcc.  Might have to do some
heavy code reading to infer it.

> 
> 
> We do use bitfields in an odd way -- for all loads and stores,
> that either have a non-zero offset or that do a type conversion,
> and it bugs me.
> 
> 
> There is something in gcc that decides if you are offseting
> more than a word into something only a word size, throw out the offset,
> or somesuch. OpenBSD/mips64 used to incorrectly access all "globals".
> "Globals" are defined by parse.c as just a block of memory
> with a name for its start, and..we don't know the size, so before
> we said it is arbitrarily small, like a word, as a workaround I
> declare that it is a arbitrarily less small:
> 
> 
> static void
> m3cg_declare_segment (void)
> {
> ...
>   /* we really don't have an idea of what the type of this var is; let's try
>      to put something that will be good enough for all the uses of this var we
>      are going to see before we have a bind_segment. Use a large size so that
>      gcc doesn't think it fits in a register, so that loads out of it do get
>      their offsets applied. */
>   TREE_TYPE (v)
>     = m3_build_type (T_struct, BIGGEST_ALIGNMENT * 2, BIGGEST_ALIGNMENT);
>   layout_decl (v, BIGGEST_ALIGNMENT);
> 
> 
> We do actually know the size though.
> The thing could be declared to be a record with typed fields
>  and we could use "component refs", except we don't bother
>  passing enough information along.
> It's related to what Tony and I said yesterday.
> 
> 
> (OpenBSD/mips64 isn't known to fully work anyway.
> But MIPS is making a comeback, see:
> http://www.openbsd.org/loongson.html
> http://www.lemote.com/en/products/all-in-one/2010/0311/122.html
> http://www.lemote.com/en/products/Notebook/2010/0310/112.html
> etc.
> )
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Sat, 15 May 2010 20:59:18 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>
>>
>>
>> Jay K wrote:
>>> I think the layout of bitfields is somewhat up to the compiler -- gcc in this case.
>>> And that bit offsets are interpreted differently for big endian and little endian.
>>> I can NOT confirm that I386_LINUX was broken.
>>> As well I had recently been working with I386_SOLARIS and AMD64_SOLARIS, without problem.
>>>
>>>
>>> I happen to then try a bunch of big endian platforms.
>>>
>>>
>>> Bitfield layout may also be subject to being defined by an ABI, and/or to matching compilers
>>> other than gcc. Like, I386_SOLARIS and I386_DARWIN and I386_LINUX could, I think, concievably,
>>> layout bitfields differently. (Heck, alignment could even cause "simpler" cases to be different,
>>> but I think it is fairly easy to come up with structs without bitfields with the "same" layout
>>> across all architectures, at least for a given wordsize/endian.)
>>>
>>>
>>> I should admit something.
>>> When I read C code with bit fields I have absolutely no idea how to compute the layout in my head.
>>> Lately for this reason I've been removing them from code where I can.
>>> Clearly they have a place, where compactness of data is of the prime importance.
>>>
>>>
>>> It's possible this is just me, that more expert programmers can readily imagine just how
>>> bitfield ought to be laid out, that all the ABIs/compilers follow the obvious rules, and that
>>> therefore they can determine the layout from glancing at the declaration.
>>>
>> According to my C '99 standard, just about everything about bit field layout is
>> implementation-defined, except for the bit count of each field. Harbison and
>> Steele (5th ed.) say pretty much the same thing and ultimately recommend coding
>> using bit-twiddling operators instead of bit fields. Failing that, they recommend
>> doing experiments with your particular compiler to verify your assumptions. Obviously
>> not possible for portable code.
>>
>> They do suggest that the fields will likely be laid out right-to-left on a little-endian
>> machine and conversely. But even there, it matters what size of "unit" is laid out
>> this way (a native word, for example) before moving on to the next unit, and that
>> is also implementation-defined.
>>
>>
>>> I just can't imagine what would be obvious.
>>> Simple example:
>>>
>>> typedef union {
>>> unsigned AsInt32;
>>> struct { unsigned a : 1 } Bits;
>>> } T1;
>>>
>>>
>>> T1 t;
>>> t.Bits.a = 1;
>>>
>>>
>>> printf("%x\n", t.AsInt32);
>>>
>>>
>>> prints 1 or 0x80000000 or what?
>>>
>>>
>>> It could be there are obvious rules, and they are endian dependent, but that otherwise
>>> all ABIs and compilers define them the same.
>>> If that is the case, I think we could get something more "optimal".
>>> However, notice how similar the "optimized" code was.
>>> And we could easily generate that without a bitfield ref.
>>> Just shift right and and with a constant, instead of shift left and then right.
>>>
>>>
>>> Could be that the decision is target-dependent as to what is optimal though.
>>>
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Sat, 15 May 2010 00:14:54 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>
>>>> COMPONENT_REF is difficult because of the lack of type info I think. Please revert to what it used to be.
>>>>
>>>>
>>>> On 14 May 2010, at 23:10, Jay K wrote:
>>>>
>>>>> http://gcc.gnu.org/ml/gcc/2006-02/msg00577.html
>>>>>
>>>>> BIT_FIELD_REF considered harmful
>>>>>
>>>>> We should try to use COMPONENT_REF instead.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu
>>>>>> Date: Sat, 15 May 2010 01:29:01 +0000
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>
>>>>>>
>>>>>> Well I'm feeling dumb. That test case surely would print 1 for almost anything.
>>>>>> A more accurate one, which shows a problem, is:
>>>>>>
>>>>>> #include
>>>>>>
>>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = 1 << 22;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> But I'm still having trouble convincing myself.
>>>>>> I guess the second might give you the 10th bit.
>>>>>> Er, the 9th.
>>>>>>
>>>>>> #include
>>>>>>
>>>>>> unsigned F1(unsigned a) { return ((a>> 22) & 1); }
>>>>>> unsigned F2(unsigned a) { return ((a << 22)>> 31); }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> unsigned a = 1 << 22;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>>
>>>>>> a = 1 << 9;
>>>>>> printf("%x %x\n", F1(a), F2(a));
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> 1 0
>>>>>> 0 1
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> Date: Sat, 15 May 2010 01:07:27 +0000
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>
>>>>>>>
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>> Er.
>>>>>>> first: a = (a>> 22) & 1;
>>>>>>> second: a = (a << 22)>> 31;
>>>>>>>
>>>>>>> are actually darn close, maybe the same.
>>>>>>> Let's just be lame and test in C:
>>>>>>>
>>>>>>> #include
>>>>>>> int main()
>>>>>>> {
>>>>>>> unsigned a = ~0;
>>>>>>> unsigned b = (a>> 22) & 1;
>>>>>>> unsigned c = (a << 22)>> 31;
>>>>>>> printf("%x %x\n", b, c);
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> both print 1. So I remain a bit uncertain.
>>>>>>> I think undoing just that one change made it go between working and not working, but I also often lose track of what I've cleaned vs. rebuilt.
>>>>>>> I might dig more before commiting the undo.
>>>>>>> Maybe bit fields of multiple bits are the only ones broken.
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Sat, 15 May 2010 00:24:03 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>
>>>>>>>>
>>>>>>>> Tony I think it is your change to extract_mn.
>>>>>>>> Try it with SOLsun for example.
>>>>>>>> I see these sorts of differences repeatedly (not to mention works vs. not works, having only undone that change):
>>>>>>>>
>>>>>>>>
>>>>>>>> diff cm3-boot-SOLsun-1/Abs.ms cm3-boot-SOLsun-2/Abs.ms
>>>>>>>> 77,78c77,78
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 118,119c118,119
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 197,198c197,198
>>>>>>>> < srl %g1, 21, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 21, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 236,237c236,237
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>> ---
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>> 273,274c273,274
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>> < and %g1, 1, %g1
>>>>>>>>
>>>>>>>>
>>>>>>>> This is not optimized.
>>>>>>>> They seem equally optimal, but very different.
>>>>>>>> Assuming shifts are fast. Could be srl+and is faster than sll+srl.
>>>>>>>> srl+and is clearer.
>>>>>>>> I don't remember which of these worked.
>>>>>>>>
>>>>>>>>
>>>>>>>> < srl %g1, 22, %g1
>>>>>>>>
>>>>>>>> < and %g1, 1, %g1
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>> sll %g1, 22, %g1
>>>>>>>>> srl %g1, 31, %g1
>>>>>>>>
>>>>>>>> I read the first as:
>>>>>>>> extract bit 22, plus or minus 1
>>>>>>>> vs.
>>>>>>>> extract bit 32-22=10, plus or minus 1.
>>>>>>>>
>>>>>>>>
>>>>>>>> It would probably be ok to move bits around, but insert would have to match.
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> Date: Fri, 14 May 2010 22:13:58 +0000
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So maybe I386_LINUX is ok..but others not..I need to test more/again/more/again/more/again....
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: RE: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>> Date: Fri, 14 May 2010 18:25:59 +0000
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I should disclose that I also rolled back hand.c, though that is mostly or completely implied, due to mod/div/set.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have some extra time today, so, plan:
>>>>>>>>>> retest head on I386_LINUX (still crossing from Darwin/x86), verify it is broken, since it is all working now
>>>>>>>>>> test undo just the bitfield insert/extract change, see if that is the problem
>>>>>>>>>> work through the others if not
>>>>>>>>>> Possibly verify mod/div test coverage (unless it is the problem, in which
>>>>>>>>>> case if I put it back, no need for test coverage, probably nobody will ever
>>>>>>>>>> touch it again, which is fine. :) )
>>>>>>>>>> I'm pretty sure I tested the set stuff well because I was very nervous but
>>>>>>>>>> if others are ruled out I'll undo or test it.
>>>>>>>>>> (To clarify, I wasn't even sure by close inspection of the correctness of my NT386
>>>>>>>>>> set changes. Only through experimentation/testing could I know that
>>>>>>>>>> the definition of bit indices matched up between hand.c and the btc/bts instructions,
>>>>>>>>>> it appeared to be a very convenient coincidence.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am surprised that I386_* working and broken.
>>>>>>>>>> I would think wordsize and endian is all that matters here.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I do worry that we are only on gcc 4.3.0 and not even 4.3.3.
>>>>>>>>>> But moving up to 4.4.x or 4.5.x is welcome too. :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>>> Date: Fri, 14 May 2010 17:58:29 +0000
>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't think anything I've been fiddling with has been dropped by gcc, yet.
>>>>>>>>>>> I might have depended on Irix o32 to get up to a working gcc, but no matter.
>>>>>>>>>>> I agree if they drop it, we have to.
>>>>>>>>>>> Though we could also keep multiple gcc versions if there was really something we wanted,
>>>>>>>>>>> but that's not likely.
>>>>>>>>>>> A C generating backend also solves this.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think I tested my "set" changes on 32bit, 64bit, little endian, big endian, all four combinations.
>>>>>>>>>>> But I won't guarantee that now and am very willing to undo them if there is a problem.
>>>>>>>>>>> (big endian 64bit would be PPC64_DARWIN, which does have a strong propensity to hang, but also largely works).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't remember about div/mod.
>>>>>>>>>>> While it seems "obvious" that the change is correct, it could be that that part of
>>>>>>>>>>> gcc is little tested: C and Fortran wouldn't use it. But maybe Ada?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm also not optimizing at all.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I also agree that rolling forward to any newer gcc is welcome. I just don't know how to do it, at least not
>>>>>>>>>>> easily, and I'm also not keen on the huge testing matrix.
>>>>>>>>>>> (I think it's roughly what I did for Apple's gcc 4.2, but it was tedious.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If it is ICEs we are after though, it is fairly easy to do cross builds and test "everything", automated, given the time to build gcc enough times. :)
>>>>>>>>>>> We should really fix the few lingering 32bit/64bit cross bugs, so we can cross build everything.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Rolling back parse.c, I think every target I've tested (running cm3 bootstrap and making
>>>>>>>>>>> sure it gets as far as "can't find cm3.cfg") has worked, except PPC32_OPENBSD.
>>>>>>>>>>> This includes PPC_DARWIN, PPC64_DARWIN, I386_LINUX, SPARC64_SOLARIS,
>>>>>>>>>>> SPARC64_OPENBSD. (SPARC64_SOLARIS now probably working).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>>>> Date: Fri, 14 May 2010 09:59:02 -0400
>>>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>
>>>>>>>>>>>> Argh. I worried about that when I made my changes, but all seemed to be well for bootstraps on Darwin/x86.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, we need to have regular testing of the compiler at both -O1 and -O2 or -O3 optimisation levels. I know of at least one gcc ICE on one platform (I forget which) that manifests only at -O3 compiling just one module in the entire CM3 distribution. This is fragile stuff... and it may just be a bug in gcc that we are exercising.
>>>>>>>>>>>>
>>>>>>>>>>>> It may be that we just need to update the backend to a newer version of gcc. It has been a couple of years, and Jay is pushing the target envelope much further than it ever has been. Problem is that newer gcc may not play nice with older targets. I strongly suggest that we focus effort on modern targets and not older targets, which implies we probably want to roll the gcc-based backend forward to a more current gcc release.
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 May 2010, at 06:27, Jay K wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> ok, bringing parse.c mostly back to what it is in release, has cleared up a lot of this, I haven't nested it all.
>>>>>>>>>>>>> Then I'll have to narrow it down some -- there are two main sets of changes:
>>>>>>>>>>>>> - my changes to set operations
>>>>>>>>>>>>> - my change to div/mod
>>>>>>>>>>>>> - Tony's to bit field operations
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is also conceivable that mixing release/head cm3 with head/release cm3cg 1) doesn't work 2) I was doing it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I thought I had tested my changes thoroughly but at this point, I don't know, and don't care much
>>>>>>>>>>>>> to keep them if they don't work.
>>>>>>>>>>>>> (Well, hopefully the NT386 versions can stay. :) )
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>> Date: Fri, 14 May 2010 09:08:58 +0000
>>>>>>>>>>>>>> Subject: Re: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hm. Something is wrong on many platforms, in head, at least with my boot archives.
>>>>>>>>>>>>>> PPC_DARWIN, SOLsun, I386_LINUX
>>>>>>>>>>>>>> I'll figure it out. Hopefully soon.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>>>>>> Date: Fri, 14 May 2010 06:37:07 +0000
>>>>>>>>>>>>>>> Subject: [M3devel] some other ports.. (PPC32_OPENBSD, SPARC64_OPENBSD, SPARC64_SOLARIS)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've tried SPARC64_OPENBSD, SPARC64_SOLARIS, PPC32_OPENBSD recently (this week).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SPARC64_SOLARIS gets far through RTLinker__InitRuntime, but ultimately bus errors in around the first line of RTType__UpdateCell, something in PolyBasis.
>>>>>>>>>>>>>>> The data in the assembly looks like. Maybe a runtime memory corruption.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> PPC32_OPENBSD complains something like in TextCat that a type is missing.
>>>>>>>>>>>>>>> I think it used to mostly work since I deleted some install I had there.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SPARC64_OPENBSD bus errors just a few instructions into RTLinker__InitRuntime.
>>>>>>>>>>>>>>> (gdb) disassem
>>>>>>>>>>>>>>> Dump of assembler code for function RTLinker__InitRuntime:
>>>>>>>>>>>>>>> 0x00000000004bd01c : save %sp, -224, %sp
>>>>>>>>>>>>>>> 0x00000000004bd020 : sethi %hi(0xd18800), %l7
>>>>>>>>>>>>>>> 0x00000000004bd024 : add %l7, 0x1fc, %l7 ! 0xd189fc
>>>>>>>>>>>>>>> 0x00000000004bd028 : call 0x4bd010 <_m3_fault+60>
>>>>>>>>>>>>>>> 0x00000000004bd02c : nop
>>>>>>>>>>>>>>> 0x00000000004bd030 : stx %i0, [ %fp + 0x87f ]
>>>>>>>>>>>>>>> 0x00000000004bd034 : stx %i1, [ %fp + 0x887 ]
>>>>>>>>>>>>>>> 0x00000000004bd038 : stx %i2, [ %fp + 0x88f ]
>>>>>>>>>>>>>>> 0x00000000004bd03c : stx %i3, [ %fp + 0x897 ]
>>>>>>>>>>>>>>> 0x00000000004bd040 : sethi %hi(0x942c00), %g1
>>>>>>>>>>>>>>> 0x00000000004bd044 : or %g1, 0x290, %g1 ! 0x942e90
>>>>>>>>>>>>>>> 0x00000000004bd048 : ldx [ %l7 + %g1 ], %g1 << here
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This seems like it'll be tough going. :(
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think I'll try with PIC turned off.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Jay
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>  		 	   		  


From hendrik at topoi.pooq.com  Wed May 19 22:54:11 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 19 May 2010 16:54:11 -0400
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
References: <DF65E9BA-21BF-4711-AC0A-8919158B96BD@cs.purdue.edu>
	<COL101-W5961A39B05A25158BB1CAFE6FE0@phx.gbl>
Message-ID: <20100519205411.GA18956@topoi.pooq.com>

On Sat, May 15, 2010 at 11:22:42PM +0000, Jay K wrote:
> 
> Fair enough. I guess random.longint() could just call random.integer() twice, or clients could, existing situation, do nothing.

I don't know how many bits of state the prwudorandom number generator 
uses, but is it has the usual 32 bits, calling random.integer() twice to 
get 64 bits does *not* give properly randome 64-bi strings.

-- hendrik


From dragisha at m3w.org  Thu May 20 12:08:53 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 20 May 2010 12:08:53 +0200
Subject: [M3devel] Linux/ARM? Android?
Message-ID: <1274350133.8902.0.camel@localhost>

As per subject... What is status of Linux/ARM port of Modula-3 and
chances for Android port?
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Thu May 20 13:47:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 11:47:56 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <1274350133.8902.0.camel@localhost>
References: <1274350133.8902.0.camel@localhost>
Message-ID: <COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>


Status is roughly nowhere.
Chances are not bad though.
There is very little work to do when the system supports posix and gcc supports the system, and that describes a lot of systems.
? Try this: cd scripts/python && ./boot1.py ARM_LINUX 


Give me ssh access to a device?
?Or maybe there is emulator?


I've had a PogoPlug (Linux/ARM) for over a year, haven't touched it.
And some I think Linux/ARM LaCie network drive also.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Thu, 20 May 2010 12:08:53 +0200
> Subject: [M3devel] Linux/ARM? Android?
>
> As per subject... What is status of Linux/ARM port of Modula-3 and
> chances for Android port?
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 13:50:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 11:50:50 +0000
Subject: [M3devel] gcc 4.5.0?
Message-ID: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>


Tony, what is involved in upgrading to gcc 4.5.0?

Import unchanged gcc.4-5.0 to the "gcc-releases" branch?

Merge it to the "gcc" branch?

And then to head?




I mean, you know..there are all the directions out there for managing
external trees, but I think the main missing detail is what
branches/tag names to use to match previous history, and it isn't
immediately clear to me..from, um, reading the history (which imho is
yet another indictment of CVS -- I can't figure out what happened).


I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
But I haven't ever updated it.
e.g. cvsup.


I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
The diffs are quite small.
But I know that's not considered the right way.


(I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)


?- Jay

 		 	   		  

From dragisha at m3w.org  Thu May 20 14:24:32 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Thu, 20 May 2010 14:24:32 +0200
Subject: [M3devel] ***SPAM*** RE:  Linux/ARM? Android?
In-Reply-To: <COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
References: <1274350133.8902.0.camel@localhost>
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
Message-ID: <1274358272.8902.2.camel@localhost>

I'll have a HTC Tattoo in a week or so. No problems then for anything.

It does not support pthread_cancel, as far as I know for now. And I
don't think we need it. Nor glibc - it's lib is bionic (didn't check it
yet).

On Thu, 2010-05-20 at 11:47 +0000, Jay K wrote:
> Status is roughly nowhere.
> Chances are not bad though.
> There is very little work to do when the system supports posix and gcc supports the system, and that describes a lot of systems.
>   Try this: cd scripts/python && ./boot1.py ARM_LINUX 
> 
> 
> Give me ssh access to a device?
>  Or maybe there is emulator?
> 
> 
> I've had a PogoPlug (Linux/ARM) for over a year, haven't touched it.
> And some I think Linux/ARM LaCie network drive also.
> 
> 
>  - Jay
> 
> ----------------------------------------
> > From: dragisha at m3w.org
> > To: m3devel at elegosoft.com
> > Date: Thu, 20 May 2010 12:08:53 +0200
> > Subject: [M3devel] Linux/ARM? Android?
> >
> > As per subject... What is status of Linux/ARM port of Modula-3 and
> > chances for Android port?
> > --
> > Dragi?a Duri? 
> >
>  		 	   		  

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



From hosking at cs.purdue.edu  Thu May 20 15:10:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 09:10:03 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>
Message-ID: <76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>

Unfortunately, it has never been as easy as import release, merge to head.  Usually there are many differences that need to be resolved by hand.  But, that is how it should be done.

And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.

As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.

On 20 May 2010, at 07:50, Jay K wrote:

> 
> Tony, what is involved in upgrading to gcc 4.5.0?
> 
> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
> 
> Merge it to the "gcc" branch?
> 
> And then to head?
> 
> 
> 
> 
> I mean, you know..there are all the directions out there for managing
> external trees, but I think the main missing detail is what
> branches/tag names to use to match previous history, and it isn't
> immediately clear to me..from, um, reading the history (which imho is
> yet another indictment of CVS -- I can't figure out what happened).
> 
> 
> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
> But I haven't ever updated it.
> e.g. cvsup.
> 
> 
> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
> The diffs are quite small.
> But I know that's not considered the right way.
> 
> 
> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
> 
> 
>  - Jay
> 
> 		 	   		  



From jay.krell at cornell.edu  Thu May 20 15:12:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 13:12:20 +0000
Subject: [M3devel] ***SPAM*** RE:  Linux/ARM? Android?
In-Reply-To: <1274358272.8902.2.camel@localhost>
References: <1274350133.8902.0.camel@localhost>,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	<1274358272.8902.2.camel@localhost>
Message-ID: <COL101-W48D5715499DCC521AABCB1E6E30@phx.gbl>


If you can provide ssh access to it and a "native" C development environment, I'll have a go at it.
By "native" C development, I mean "official", not necessarily "hosted on the target machine".
If the C development environment is easily acquired, I can do that part. It probably is.
There's a possibility, possibility, we should have separate ARM_LINUX and ARM_ANROID or or ARM_GNU_LINUX or ARM_BIONIC_LINUX or ARM_LINUX_ANDROID or ARM_LINUX_GOOGLE or ARM_GOOGLE or ARM_LINUX_GOOGLE or ARM_GOOGLE_LINUX or ARM_OHSA_LINUX ("open handset aliance?") or such.


In particular, if there jmpbuf sizes are different, then we should.
The "Modula-3 compiler" cares only about: endian, word size, jmpbuf size, basically that's it.
?Alignment too, but they are all the same.
?"Code alignment" too, some of each, for the closure stuff.


If they aren't binary compatible, then we probably should -- just to propagate it out to the naming of packages really.


There is "something" nagging to get out that isn't a "target" or? "platform" but something like a "configuration".
?For example, SOLsun and SOLgnu are the same, except for which C compiler they use to compiler a few files, and for the C-compiler-as-linker-driver.
? They have the same jumpbuf, the same stack walker, they end up with the same #ifs in the C code, at least wrt #if __sun, not #if __GNUC__.


Basically it seems that "platform" = "kernel" + "C library" + processor + "sometimes C compiler/linker" + "Windowing system" + "GUI library" + "file i/o library"
But many of them correlate very very strongly.
"C library" varies -- uclibc, dietlibc, glibc, eglibc, bionic.
file i/o library = posix or win32
threads = pthreads or posix user threads perhaps or win32
?? (ie: we should have separate I386_LINUX_USERTHREADS?)


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 20 May 2010 14:24:32 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ***SPAM*** RE: Linux/ARM? Android?
>
> I'll have a HTC Tattoo in a week or so. No problems then for anything.
>
> It does not support pthread_cancel, as far as I know for now. And I
> don't think we need it. Nor glibc - it's lib is bionic (didn't check it
> yet).
>
> On Thu, 2010-05-20 at 11:47 +0000, Jay K wrote:
>> Status is roughly nowhere.
>> Chances are not bad though.
>> There is very little work to do when the system supports posix and gcc supports the system, and that describes a lot of systems.
>> Try this: cd scripts/python && ./boot1.py ARM_LINUX
>>
>>
>> Give me ssh access to a device?
>> Or maybe there is emulator?
>>
>>
>> I've had a PogoPlug (Linux/ARM) for over a year, haven't touched it.
>> And some I think Linux/ARM LaCie network drive also.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: dragisha at m3w.org
>>> To: m3devel at elegosoft.com
>>> Date: Thu, 20 May 2010 12:08:53 +0200
>>> Subject: [M3devel] Linux/ARM? Android?
>>>
>>> As per subject... What is status of Linux/ARM port of Modula-3 and
>>> chances for Android port?
>>> --
>>> Dragi?a Duri?
>>>
>>
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 15:21:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 13:21:09 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>
Message-ID: <COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>


eh, ok, I'll try that then.


Have you noticed what I did for OpenBSD?
Perhaps easier to just commit those diffs?
In order to facilitate merging?
Tedious either way of course.


What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
?? OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
Largely they aren't relevant, like to c-*.c.
Largely they are trivial. Just configure/makefile snippets.
Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
We apply them during our build, in m3makefile.


Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
And commit with minimal testing instead of a big matrix.


But it bloats the source tree a lot.


I'd also like to somehow reduce how often gmp and mpfr are built.
They are a huge fraction of the time.
And 4.5.0 adds another similar library, mpc.
? "c" for complex numbers..more stuff we don't use...


It seems our main changes are:
? introducing of static chain for nested procedures
? Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
? Or Pascal? I mean..do we have to add our own?

? small hacks to inhibit optimization 


? the little makefile machinery 


Also, have you noticed that 4.5.0 has a "plugin" interface?
Perhaps we can just use that, and just distribute a small .so file.
At least once 4.5.0 is in wide use.


?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 09:10:03 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>
> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>
> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>
> On 20 May 2010, at 07:50, Jay K wrote:
>
>>
>> Tony, what is involved in upgrading to gcc 4.5.0?
>>
>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>
>> Merge it to the "gcc" branch?
>>
>> And then to head?
>>
>>
>>
>>
>> I mean, you know..there are all the directions out there for managing
>> external trees, but I think the main missing detail is what
>> branches/tag names to use to match previous history, and it isn't
>> immediately clear to me..from, um, reading the history (which imho is
>> yet another indictment of CVS -- I can't figure out what happened).
>>
>>
>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>> But I haven't ever updated it.
>> e.g. cvsup.
>>
>>
>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>> The diffs are quite small.
>> But I know that's not considered the right way.
>>
>>
>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>
>>
>> - Jay
>>
>>
>
 		 	   		  

From mika at async.async.caltech.edu  Thu May 20 15:44:37 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 20 May 2010 06:44:37 -0700
Subject: [M3devel] random.longint()?
In-Reply-To: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl> 
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>
Message-ID: <20100520134437.D15551A2094@async.async.caltech.edu>


I would be a bit careful here.  Presumably there are a lot of subtypes
of Random.T out there that override methods in various ways...  Layering
longint on top of multiple calls to integer (rather than the other way
around) seems like the safe approach to getting things working.

   Mika

Jay K writes:
>
>In libm3 there is random number generation.
>In libm3 that is code that wants 8 random bytes.
>=A0 If integer is 4 bytes=2C it calls random.integer() twice=2C else if it =
>is 8=2C once.
>
>It seems natural that we should provide random.longint()?
>
>And then the other code can just use it?
>
>Someone can look into the random number generator and
>=A0- make sure it is actually "correct" for 64bit integer?
>=A0- and if so=2C change the lowest level to use LONGINT
>=A0=A0 and layer integer over it? -- not sure how=2C presumably
>=A0=A0 taking only the lower 32bits loses too much randomness?
>
>
>This is what I get for looking into why we are ever asked to extract 0 bits=
>..
>
>"Everywhere I look=2C I see bugs." (topic of a separate mail)
>
>=A0- Jay
>
> 		 	   		  =


From hosking at cs.purdue.edu  Thu May 20 15:54:14 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 09:54:14 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>
Message-ID: <2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>



On 20 May 2010, at 09:21, Jay K wrote:

> 
> eh, ok, I'll try that then.
> 
> 
> Have you noticed what I did for OpenBSD?
> Perhaps easier to just commit those diffs?
> In order to facilitate merging?
> Tedious either way of course.
> 
> 
> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>    OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
> Largely they aren't relevant, like to c-*.c.
> Largely they are trivial. Just configure/makefile snippets.
> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
> We apply them during our build, in m3makefile.
> 
> 
> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
> And commit with minimal testing instead of a big matrix.
> 
> 
> But it bloats the source tree a lot.
> 
> 
> I'd also like to somehow reduce how often gmp and mpfr are built.
> They are a huge fraction of the time.
> And 4.5.0 adds another similar library, mpc.
>   "c" for complex numbers..more stuff we don't use...
> 
> 
> It seems our main changes are:
>   introducing of static chain for nested procedures
>   Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>   Or Pascal? I mean..do we have to add our own?

Yes, we need the support for extracting the static chain for passing with procedure arguments.  Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain).  i.e., they are "static" closures.

>   small hacks to inhibit optimisation

It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.

>   the little makefile machinery 
> 
> 
> Also, have you noticed that 4.5.0 has a "plugin" interface?

Yes, I'd heard about that.

> Perhaps we can just use that, and just distribute a small .so file.

That would be *very* cool.

> At least once 4.5.0 is in wide use.

Right.

> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 20 May 2010 09:10:03 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>> 
>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>> 
>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>> 
>> On 20 May 2010, at 07:50, Jay K wrote:
>> 
>>> 
>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>> 
>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>> 
>>> Merge it to the "gcc" branch?
>>> 
>>> And then to head?
>>> 
>>> 
>>> 
>>> 
>>> I mean, you know..there are all the directions out there for managing
>>> external trees, but I think the main missing detail is what
>>> branches/tag names to use to match previous history, and it isn't
>>> immediately clear to me..from, um, reading the history (which imho is
>>> yet another indictment of CVS -- I can't figure out what happened).
>>> 
>>> 
>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>> But I haven't ever updated it.
>>> e.g. cvsup.
>>> 
>>> 
>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>> The diffs are quite small.
>>> But I know that's not considered the right way.
>>> 
>>> 
>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>> 
>>> 
>>> - Jay
>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Thu May 20 16:01:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 14:01:09 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
Message-ID: <COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>


What I meant regarding "static chain" was more like "does gcc already have support that we can use".
Don't any of the other languages need it already?
Ada? Pascal? Maybe the nested C function support?

?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 09:54:14 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
>
>
> On 20 May 2010, at 09:21, Jay K wrote:
>
>>
>> eh, ok, I'll try that then.
>>
>>
>> Have you noticed what I did for OpenBSD?
>> Perhaps easier to just commit those diffs?
>> In order to facilitate merging?
>> Tedious either way of course.
>>
>>
>> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>> OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
>> Largely they aren't relevant, like to c-*.c.
>> Largely they are trivial. Just configure/makefile snippets.
>> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
>> We apply them during our build, in m3makefile.
>>
>>
>> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
>> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
>> And commit with minimal testing instead of a big matrix.
>>
>>
>> But it bloats the source tree a lot.
>>
>>
>> I'd also like to somehow reduce how often gmp and mpfr are built.
>> They are a huge fraction of the time.
>> And 4.5.0 adds another similar library, mpc.
>> "c" for complex numbers..more stuff we don't use...
>>
>>
>> It seems our main changes are:
>> introducing of static chain for nested procedures
>> Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>> Or Pascal? I mean..do we have to add our own?
>
> Yes, we need the support for extracting the static chain for passing with procedure arguments. Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain). i.e., they are "static" closures.
>
>> small hacks to inhibit optimisation
>
> It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.
>
>> the little makefile machinery
>>
>>
>> Also, have you noticed that 4.5.0 has a "plugin" interface?
>
> Yes, I'd heard about that.
>
>> Perhaps we can just use that, and just distribute a small .so file.
>
> That would be *very* cool.
>
>> At least once 4.5.0 is in wide use.
>
> Right.
>
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 20 May 2010 09:10:03 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>>>
>>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>>>
>>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>>>
>>> On 20 May 2010, at 07:50, Jay K wrote:
>>>
>>>>
>>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>>>
>>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>>>
>>>> Merge it to the "gcc" branch?
>>>>
>>>> And then to head?
>>>>
>>>>
>>>>
>>>>
>>>> I mean, you know..there are all the directions out there for managing
>>>> external trees, but I think the main missing detail is what
>>>> branches/tag names to use to match previous history, and it isn't
>>>> immediately clear to me..from, um, reading the history (which imho is
>>>> yet another indictment of CVS -- I can't figure out what happened).
>>>>
>>>>
>>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>>> But I haven't ever updated it.
>>>> e.g. cvsup.
>>>>
>>>>
>>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>>> The diffs are quite small.
>>>> But I know that's not considered the right way.
>>>>
>>>>
>>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 16:04:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 14:04:45 +0000
Subject: [M3devel] random.longint()?
In-Reply-To: <20100520134437.D15551A2094@async.async.caltech.edu>
References: <COL101-W9BC85C40135194AFFF259E6FE0@phx.gbl>,
	<20100520134437.D15551A2094@async.async.caltech.edu>
Message-ID: <COL101-W6248BB81D2C8DF3DF0D94AE6E30@phx.gbl>


I'm just going to leave it alone.
There's already code that checks BITSIZE(INTEGER) and makes one or two calls accordingly.


More interesting probably..but again probably nothing from me..is using modern OS
sources of randomness, entropy, random numbers.


http://www.opengroup.org/onlinepubs/007908799/xsh/drand48.html
http://en.wikipedia.org/wiki/CryptGenRandom


You know..sometimes underlying system doesn't offer much and you do it yourself.
Sometimes the underlying systems catch up..


?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] random.longint()?
> Date: Thu, 20 May 2010 06:44:37 -0700
> From: mika at async.async.caltech.edu
>
>
> I would be a bit careful here. Presumably there are a lot of subtypes
> of Random.T out there that override methods in various ways... Layering
> longint on top of multiple calls to integer (rather than the other way
> around) seems like the safe approach to getting things working.
>
> Mika
>
> Jay K writes:
>>
>>In libm3 there is random number generation.
>>In libm3 that is code that wants 8 random bytes.
>>=A0 If integer is 4 bytes=2C it calls random.integer() twice=2C else if it =
>>is 8=2C once.
>>
>>It seems natural that we should provide random.longint()?
>>
>>And then the other code can just use it?
>>
>>Someone can look into the random number generator and
>>=A0- make sure it is actually "correct" for 64bit integer?
>>=A0- and if so=2C change the lowest level to use LONGINT
>>=A0=A0 and layer integer over it? -- not sure how=2C presumably
>>=A0=A0 taking only the lower 32bits loses too much randomness?
>>
>>
>>This is what I get for looking into why we are ever asked to extract 0 bits=
>>..
>>
>>"Everywhere I look=2C I see bugs." (topic of a separate mail)
>>
>>=A0- Jay
>>
>> =
 		 	   		  

From jay.krell at cornell.edu  Thu May 20 15:59:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 13:59:53 +0000
Subject: [M3devel] limiting .so exports
Message-ID: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>


limiting .so exports
?(and direct binding to symbols in same .so)


FYI:


No clear question here, just a heads up regarding stuff that might be coming.



I'm working on limiting .so exports to only "what they should be".


In particular, given:

INTERFACE Foo;

PROCEDURE Bar();

END Foo.

MODULE Foo;

PROCEDURE F() = BEGIN ... END F;

PROCEDURE Bar() = BEGIN F(); END Bar;

END Foo.


Foo__F should not exported.
Foo__Bar should be.


Today they both would be.
Or at least in the recent past.
?I already made a change in parse.c to reduce things.


However at that level I don't believe we have the needed information.
? (needs investigation)


What I have is that in MxOut.m3, I write out all the symbols in
import_def_syms for modules.
Plus the _M3 and _I3 symbols.


That is most of the work.
However there are missing or non-ideal parts.


In the config files I then transform the list into the format
required by the compiler/linker. I was doing the transform in MxOut.m3
but it was getting to be "too much" work.


You also need to export anything marked <* EXTERNAL *> in interfaces.
I can get that list, however I have been using the "trick" of not
always implementing all EXTERNALs.
Sometimes the C implementation has #ifdefs around it.
So that becomes difficult.


gcc has __attribute__ and #pragma GCC visibility to control things
also, but this seems to conflict with giving a list in a file to
the compiler/linker.


What I have currently is that after compiling any C file, I run
nm on it to get its symbols.


I combine the nm output with the MxOut.m3 output.


Unfortunately that exports more of the C code than intended.
But code that always was exported -- like all of ThreadPThread.c.


As well something I haven't fixed yet is that lowercase interface
contents should not be exported, only capital Interface.


The list would be presented with
? GNU ld: --version-script
? Sun ld: -M for mapfile
? Mac ld: --export-symbol-list


Sun ld and GNU ld accept roughly the same input.


I'm not sure how these two mechanisms compare.
It could be that it is better to use source/parse.c-level "visibility"
and not present the lists to the linker.
In particular that allows for not exporting more of the C.


I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.


The "list" approach should probably at least be used on NT/Cygwin.
Currently we export everything by mklib enumerating the symbols.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Thu May 20 16:50:42 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 10:50:42 -0400
Subject: [M3devel] limiting .so exports
In-Reply-To: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>
References: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>
Message-ID: <4940E887-0077-434D-A63E-88D76D6E76DA@cs.purdue.edu>

Can we not just push more information through to the back-ends for import_global/import_procedure?  The front-end would need to know where it found the import (in the local package or in another imported package) but all that information would be derivable from m3linker wouldn't it?




On 20 May 2010, at 09:59, Jay K wrote:

> 
> limiting .so exports
>  (and direct binding to symbols in same .so)
> 
> 
> FYI:
> 
> 
> No clear question here, just a heads up regarding stuff that might be coming.
> 
> 
> 
> I'm working on limiting .so exports to only "what they should be".
> 
> 
> In particular, given:
> 
> INTERFACE Foo;
> 
> PROCEDURE Bar();
> 
> END Foo.
> 
> MODULE Foo;
> 
> PROCEDURE F() = BEGIN ... END F;
> 
> PROCEDURE Bar() = BEGIN F(); END Bar;
> 
> END Foo.
> 
> 
> Foo__F should not exported.
> Foo__Bar should be.
> 
> 
> Today they both would be.
> Or at least in the recent past.
>  I already made a change in parse.c to reduce things.
> 
> 
> However at that level I don't believe we have the needed information.
>   (needs investigation)
> 
> 
> What I have is that in MxOut.m3, I write out all the symbols in
> import_def_syms for modules.
> Plus the _M3 and _I3 symbols.
> 
> 
> That is most of the work.
> However there are missing or non-ideal parts.
> 
> 
> In the config files I then transform the list into the format
> required by the compiler/linker. I was doing the transform in MxOut.m3
> but it was getting to be "too much" work.
> 
> 
> You also need to export anything marked <* EXTERNAL *> in interfaces.
> I can get that list, however I have been using the "trick" of not
> always implementing all EXTERNALs.
> Sometimes the C implementation has #ifdefs around it.
> So that becomes difficult.
> 
> 
> gcc has __attribute__ and #pragma GCC visibility to control things
> also, but this seems to conflict with giving a list in a file to
> the compiler/linker.
> 
> 
> What I have currently is that after compiling any C file, I run
> nm on it to get its symbols.
> 
> 
> I combine the nm output with the MxOut.m3 output.
> 
> 
> Unfortunately that exports more of the C code than intended.
> But code that always was exported -- like all of ThreadPThread.c.
> 
> 
> As well something I haven't fixed yet is that lowercase interface
> contents should not be exported, only capital Interface.
> 
> 
> The list would be presented with
>   GNU ld: --version-script
>   Sun ld: -M for mapfile
>   Mac ld: --export-symbol-list
> 
> 
> Sun ld and GNU ld accept roughly the same input.
> 
> 
> I'm not sure how these two mechanisms compare.
> It could be that it is better to use source/parse.c-level "visibility"
> and not present the lists to the linker.
> In particular that allows for not exporting more of the C.
> 
> 
> I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.
> 
> 
> The "list" approach should probably at least be used on NT/Cygwin.
> Currently we export everything by mklib enumerating the symbols.
> 
> 
>  - Jay
> 		 	   		  



From hosking at cs.purdue.edu  Thu May 20 16:52:03 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 10:52:03 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
Message-ID: <DAB881D4-AB78-4C8D-842A-3A9448AA5B6A@cs.purdue.edu>

Yes, we do make use of some of gcc's static chain machinery.  We just avoid the need for the trampolines that gcc uses because we need a reified static chain that is otherwise computed in the trampoline on the way to calling a nested procedure.

On 20 May 2010, at 10:01, Jay K wrote:

> 
> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
> Don't any of the other languages need it already?
> Ada? Pascal? Maybe the nested C function support?
> 
>  - Jay
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 20 May 2010 09:54:14 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> 
>> 
>> On 20 May 2010, at 09:21, Jay K wrote:
>> 
>>> 
>>> eh, ok, I'll try that then.
>>> 
>>> 
>>> Have you noticed what I did for OpenBSD?
>>> Perhaps easier to just commit those diffs?
>>> In order to facilitate merging?
>>> Tedious either way of course.
>>> 
>>> 
>>> What I did for OpenBSD -- commited long ago, been working -- is that there are diffs out there, like in the OpenBSD port system.
>>> OpenBSD apparently sticks with patched 2.95 for some systems, patched 3.x mostly, and OpenBSD isn't quite supported by mainline gcc.
>>> Largely they aren't relevant, like to c-*.c.
>>> Largely they are trivial. Just configure/makefile snippets.
>>> Anyway, I took the ones we needed, possibly edited them to compile, checked them in.
>>> We apply them during our build, in m3makefile.
>>> 
>>> 
>>> Another wasteful but lazy option is import gcc-4.5.0 as a new directory and
>>> only shift targets to it upon (minimal) testing. That way I can put off the OpenBSD thing.
>>> And commit with minimal testing instead of a big matrix.
>>> 
>>> 
>>> But it bloats the source tree a lot.
>>> 
>>> 
>>> I'd also like to somehow reduce how often gmp and mpfr are built.
>>> They are a huge fraction of the time.
>>> And 4.5.0 adds another similar library, mpc.
>>> "c" for complex numbers..more stuff we don't use...
>>> 
>>> 
>>> It seems our main changes are:
>>> introducing of static chain for nested procedures
>>> Doesn't Ada have them? I've noticed that Ada "looks like" Modula-3.
>>> Or Pascal? I mean..do we have to add our own?
>> 
>> Yes, we need the support for extracting the static chain for passing with procedure arguments. Recall that a procedure argument in Modula-3 consists of both a code pointer and an environment (static chain). i.e., they are "static" closures.
>> 
>>> small hacks to inhibit optimisation
>> 
>> It would be great to get rid of these, but it would involve implementing the language-specific alias analysis support that gcc's optimisers need much more fully.
>> 
>>> the little makefile machinery
>>> 
>>> 
>>> Also, have you noticed that 4.5.0 has a "plugin" interface?
>> 
>> Yes, I'd heard about that.
>> 
>>> Perhaps we can just use that, and just distribute a small .so file.
>> 
>> That would be *very* cool.
>> 
>>> At least once 4.5.0 is in wide use.
>> 
>> Right.
>> 
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Thu, 20 May 2010 09:10:03 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>> 
>>>> Unfortunately, it has never been as easy as import release, merge to head. Usually there are many differences that need to be resolved by hand. But, that is how it should be done.
>>>> 
>>>> And in past releases (from v3 to v4) things have changed so drastically in gcc that it has been practically a full report.
>>>> 
>>>> As can be seen from the history I previously used the approach you mention last: diff against the reference release and roll the diffs forward into the new version by reapplying the diffs. To be honest I find that better because it forces you to look at every diff in context, so you catch any incompatible changes.
>>>> 
>>>> On 20 May 2010, at 07:50, Jay K wrote:
>>>> 
>>>>> 
>>>>> Tony, what is involved in upgrading to gcc 4.5.0?
>>>>> 
>>>>> Import unchanged gcc.4-5.0 to the "gcc-releases" branch?
>>>>> 
>>>>> Merge it to the "gcc" branch?
>>>>> 
>>>>> And then to head?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> I mean, you know..there are all the directions out there for managing
>>>>> external trees, but I think the main missing detail is what
>>>>> branches/tag names to use to match previous history, and it isn't
>>>>> immediately clear to me..from, um, reading the history (which imho is
>>>>> yet another indictment of CVS -- I can't figure out what happened).
>>>>> 
>>>>> 
>>>>> I have gone through the exercise a very small number of times, like once, of importing foreign source into cvs.
>>>>> But I haven't ever updated it.
>>>>> e.g. cvsup.
>>>>> 
>>>>> 
>>>>> I can also easily enough diff our tree against gcc-4.3.0, overwrite with 4.5.0, and reapply the diffs.
>>>>> The diffs are quite small.
>>>>> But I know that's not considered the right way.
>>>>> 
>>>>> 
>>>>> (I'm still hoping to switch, like to mercurial or maybe git or maybe monotone..)
>>>>> 
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 		 	   		  



From jay.krell at cornell.edu  Thu May 20 17:28:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 20 May 2010 15:28:19 +0000
Subject: [M3devel] limiting .so exports
In-Reply-To: <4940E887-0077-434D-A63E-88D76D6E76DA@cs.purdue.edu>
References: <COL101-W5731FBCD3CCC9A4E86D672E6E30@phx.gbl>,
	<4940E887-0077-434D-A63E-88D76D6E76DA@cs.purdue.edu>
Message-ID: <COL101-W51B9331953E9EB9AA6B2FAE6E30@phx.gbl>


I'm not sure of much right now, I have to rest and come back.

I'm quite dissatisifed with gcc/gnuld currently.
I don't want to tell the compiler anything really.
I want all function calls to always use x86 0xE8 opcode which is a direct pc-relative call, and then have the linker generate small stubs for anything that ends up external.
? That is how NT/x86 works and it is reasonably simple and efficient. Cross-.so calls would be slightly penalized, since if you did tell the compiler about them, it might inline the stub at the call. (The NT/x86 stubs are just one jmp instruction, but they aren't necessarily position-independent).
And I want to mostly give the linker a list of exports, plus maybe a few source annotations for exports.
I'd like source annotations and the lists to be additive. Maybe the "local: *" in my current code is wrong.


There seem to be so many features/switches, and it is hard/impossible to extract something simple, understandable, efficient.
I have trouble getting a mental model of how ld/ld.so work on most platforms.
The model on NT seems simple..

Attached is what I have so far..but I'm not entirely happy with it..
It is disabled in its current form.

It would also be nice if visibility(protected) worked.
It does sometimes, for calls, but not for taking the address of a function.

Anyway...
?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 10:50:42 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] limiting .so exports
>
> Can we not just push more information through to the back-ends for import_global/import_procedure? The front-end would need to know where it found the import (in the local package or in another imported package) but all that information would be derivable from m3linker wouldn't it?
>
>
>
>
> On 20 May 2010, at 09:59, Jay K wrote:
>
>>
>> limiting .so exports
>> (and direct binding to symbols in same .so)
>>
>>
>> FYI:
>>
>>
>> No clear question here, just a heads up regarding stuff that might be coming.
>>
>>
>>
>> I'm working on limiting .so exports to only "what they should be".
>>
>>
>> In particular, given:
>>
>> INTERFACE Foo;
>>
>> PROCEDURE Bar();
>>
>> END Foo.
>>
>> MODULE Foo;
>>
>> PROCEDURE F() = BEGIN ... END F;
>>
>> PROCEDURE Bar() = BEGIN F(); END Bar;
>>
>> END Foo.
>>
>>
>> Foo__F should not exported.
>> Foo__Bar should be.
>>
>>
>> Today they both would be.
>> Or at least in the recent past.
>> I already made a change in parse.c to reduce things.
>>
>>
>> However at that level I don't believe we have the needed information.
>> (needs investigation)
>>
>>
>> What I have is that in MxOut.m3, I write out all the symbols in
>> import_def_syms for modules.
>> Plus the _M3 and _I3 symbols.
>>
>>
>> That is most of the work.
>> However there are missing or non-ideal parts.
>>
>>
>> In the config files I then transform the list into the format
>> required by the compiler/linker. I was doing the transform in MxOut.m3
>> but it was getting to be "too much" work.
>>
>>
>> You also need to export anything marked <* EXTERNAL *> in interfaces.
>> I can get that list, however I have been using the "trick" of not
>> always implementing all EXTERNALs.
>> Sometimes the C implementation has #ifdefs around it.
>> So that becomes difficult.
>>
>>
>> gcc has __attribute__ and #pragma GCC visibility to control things
>> also, but this seems to conflict with giving a list in a file to
>> the compiler/linker.
>>
>>
>> What I have currently is that after compiling any C file, I run
>> nm on it to get its symbols.
>>
>>
>> I combine the nm output with the MxOut.m3 output.
>>
>>
>> Unfortunately that exports more of the C code than intended.
>> But code that always was exported -- like all of ThreadPThread.c.
>>
>>
>> As well something I haven't fixed yet is that lowercase interface
>> contents should not be exported, only capital Interface.
>>
>>
>> The list would be presented with
>> GNU ld: --version-script
>> Sun ld: -M for mapfile
>> Mac ld: --export-symbol-list
>>
>>
>> Sun ld and GNU ld accept roughly the same input.
>>
>>
>> I'm not sure how these two mechanisms compare.
>> It could be that it is better to use source/parse.c-level "visibility"
>> and not present the lists to the linker.
>> In particular that allows for not exporting more of the C.
>>
>>
>> I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.
>>
>>
>> The "list" approach should probably at least be used on NT/Cygwin.
>> Currently we export everything by mklib enumerating the symbols.
>>
>>
>> - Jay
>>
>
 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exports.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100520/f98ad3ee/attachment-0002.txt>

From rodney_bates at lcwb.coop  Thu May 20 19:12:00 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 20 May 2010 12:12:00 -0500
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>
Message-ID: <4BF56D60.2000403@lcwb.coop>

gcc even extends C with nested functions, and the support is there for that.  We use it too.

Beware:  The runtime model is, IMO, bizarre.  Definitely counterintuitive and unlike anything
you will ever see elsewhere.  There are two static links.  One is used for the first step
in following a static chain and points to the expected place in the target frame.  The other
is used of subsequent steps in chain-following, and points to somewhere inside the target
frame that is dependent on the target procedure.  It's the beginning of a subrecord where
all the nonlocally-referenced variables are collected.  The second static link is also
located in there.  All the nonlocally-referenced variables and parameters are duplicated
in there too.

I'm not sure I remembered these details exactly right.  Maybe both links point to the
subrecord, but one is located at a traditional procedure-independent, fixed location
in the frame, while the second is located in the subrecord.  Also, sometimes the first
static link value is kept in a register and never stored.

What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
scheme that, I believe came from interaction between nested procedures and inlining them.

But it's at the cost of what I would call an insanely complicated _runtime_ scheme.

It undermined m3gdb's handling of static links, and I don't think it's possible to fix
with the current design of emitting debug info very early.  The locations and target
offsets of these things aren't know until later, and m3gdb really needs to know them.


Jay K wrote:
> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
> Don't any of the other languages need it already?
> Ada? Pascal? Maybe the nested C function support?
> 
>  - Jay
> 


From jay.krell at cornell.edu  Fri May 21 03:43:08 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 01:43:08 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <4BF56D60.2000403@lcwb.coop>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>,
	, , <76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	<4BF56D60.2000403@lcwb.coop>
Message-ID: <COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>


Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
 
 
The static link is an extra parameter.
And, as such, also an extra local variable.
You only need one.
Each nesting level would follow another chain.
Or you can pass each nesting level as an extra parameter.
Or you can optimize and pass locals/parameters separately.
But there is an obvious straightforward non-optimized form. ?
 
 
Here, I worked it through:
 
 
 
Why doesn't it just look something like this:
 
 
nested:
 
void F1(int a, int b)
{
  int c = a + b;
 
  int f2()
  {
    int d = a + b;
 
    int f3()
    {
       return d + a + c;
    }
 
    return a + c + f3();
  }
 
  return f2();
}
 
not nested:
 

typedef struct {
  /* locals */
  int d;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
  f1_frame_t* f1;
} f2_frame_t;
 

typedef struct {
  /* locals */
  int c;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
  int a;
  int b;
} f1_frame_t;
 
 
int f3(f2_frame_t* f2)
{
    return f2->d + f2->f1->a + f2->f1->c;
}
 

int f2(f1_frame_t* f1)
{
  int d = f1->a + f1->b;
  return f1->a + f1->c + f3((f2_frame_t*)&d);
}
 

int F1(int a, int b)
{
  int c = a + b;
  return f2((f1_frame_t*)&c);
}

 
or, alernatively, almost the same, pass each chain as another parameter:
 

typedef struct {
  /* locals */
  int d;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
} f2_frame_t;
 

typedef struct {
  /* locals */
  int c;
  void* x86_frame_pointer;
  void* x86_return_address;
  /* parameters */
  int a;
  int b;
} f1_frame_t;
 
 
int f3(f2_frame_t* f2, f1_frame_t* f1)
{
    return f2->d + f1->a + f1->c;
}
 
 

int f2(f1_frame_t* f1)
{
  int d = f1->a + f1->b;
  return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
}
 

int F1(int a, int b)
{
  int c = a + b;
  return f2((f1_frame_t*)&c);
}
 
 
This should be easily adapted to any function call convention/sequence.
e.g. even if parameters are passed in registers.
 
 
And for that matter, why don't we just transform it to be like this?
  With the goal of reducing/eliminating gcc patches?
 
 
Am I missing something?
 

This form doesn't work?
 

Isn't reasonably simple?
 

Granted it might not be optimal. But it depends.
  You know, you can copy in the local/parameter values, but then you have
   to copy them out too. You can do analysis to show they aren't changed,
   in which case no need to copy them out.
  Similarly you can pass the parameters as separate parameters, by address
   if they are ever changed.

 
A portable transform couldn't depend on adjacency of locals and parameters.
It would have to either copy the parameters into the frame_t, or their addresses.
 
 
A portable form couldn't get the frame by taking the address of a "individual" local.
 
 
Here is portable form:
 
 
typedef struct {
  int d;
  f1_frame_t* f1;
} f2_frame_t;
 
typedef struct {
  int a;
  int b;
  int c;
} f1_frame_t;
 

int f3(f2_frame_t* f2)
{
    return f2->d + f2->f1->a + f2->f1->c;
}
 
int f2(f1_frame_t* f1)
{
  f2_frame_t f;
  f.f1 = f1;
  f.d = f1->a + f1->b;
  return f1->a + f1->c + f3(&f);
}
 
 
int F1(int a, int b)
{
  f1_frame_t f;
  f.a = a;
  f.b = b;
  f.c = a + b;
  return f2(&f);
}
 
 
or:
 
 
typedef struct {
  int d;
} f2_frame_t;
 
 
typedef struct {
  int a;
  int b;
  int c;
} f1_frame_t;
 
 
int f3(f2_frame_t* f2, f1_frame_t* f1)
{
    return f2->d + f1->a + f1->c;
}
 
 
int f2(f1_frame_t* f1)
{
  f2_frame_t f;
  f.d = f1->a + f1->b;
  return f1->a + f1->c + f3(&f, f1);
}

 
int F1(int a, int b)
{
  f1_frame_t f;
  f.a = a;
  f.b = b;
  f.c = a + b;
  return f2(&f);
}

 
 
 
 - Jay



----------------------------------------
> Date: Thu, 20 May 2010 12:12:00 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> gcc even extends C with nested functions, and the support is there for that. We use it too.
>
> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
> you will ever see elsewhere. There are two static links. One is used for the first step
> in following a static chain and points to the expected place in the target frame. The other
> is used of subsequent steps in chain-following, and points to somewhere inside the target
> frame that is dependent on the target procedure. It's the beginning of a subrecord where
> all the nonlocally-referenced variables are collected. The second static link is also
> located in there. All the nonlocally-referenced variables and parameters are duplicated
> in there too.
>
> I'm not sure I remembered these details exactly right. Maybe both links point to the
> subrecord, but one is located at a traditional procedure-independent, fixed location
> in the frame, while the second is located in the subrecord. Also, sometimes the first
> static link value is kept in a register and never stored.
>
> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
> scheme that, I believe came from interaction between nested procedures and inlining them.
>
> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>
> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
> with the current design of emitting debug info very early. The locations and target
> offsets of these things aren't know until later, and m3gdb really needs to know them.
>
>
> Jay K wrote:
>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>> Don't any of the other languages need it already?
>> Ada? Pascal? Maybe the nested C function support?
>>
>> - Jay
>> 		 	   		  

From hosking at cs.purdue.edu  Fri May 21 04:22:46 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 20 May 2010 22:22:46 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	<4BF56D60.2000403@lcwb.coop>
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
Message-ID: <AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>

That is the standard formulation, but different architectures have different optimised forms (passing static link in a register, etc.).  In any case, gcc has its own weird way of doing things, which we mostly use, but from which we need a little extra support (hence the small amount of special tailoring).

On 20 May 2010, at 21:43, Jay K wrote:

> 
> Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
> 
> 
> The static link is an extra parameter.
> And, as such, also an extra local variable.
> You only need one.
> Each nesting level would follow another chain.
> Or you can pass each nesting level as an extra parameter.
> Or you can optimize and pass locals/parameters separately.
> But there is an obvious straightforward non-optimized form. ?
> 
> 
> Here, I worked it through:
> 
> 
> 
> Why doesn't it just look something like this:
> 
> 
> nested:
> 
> void F1(int a, int b)
> {
>  int c = a + b;
> 
>  int f2()
>  {
>    int d = a + b;
> 
>    int f3()
>    {
>       return d + a + c;
>    }
> 
>    return a + c + f3();
>  }
> 
>  return f2();
> }
> 
> not nested:
> 
> 
> typedef struct {
>  /* locals */
>  int d;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
>  f1_frame_t* f1;
> } f2_frame_t;
> 
> 
> typedef struct {
>  /* locals */
>  int c;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
>  int a;
>  int b;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2)
> {
>    return f2->d + f2->f1->a + f2->f1->c;
> }
> 
> 
> int f2(f1_frame_t* f1)
> {
>  int d = f1->a + f1->b;
>  return f1->a + f1->c + f3((f2_frame_t*)&d);
> }
> 
> 
> int F1(int a, int b)
> {
>  int c = a + b;
>  return f2((f1_frame_t*)&c);
> }
> 
> 
> or, alernatively, almost the same, pass each chain as another parameter:
> 
> 
> typedef struct {
>  /* locals */
>  int d;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
> } f2_frame_t;
> 
> 
> typedef struct {
>  /* locals */
>  int c;
>  void* x86_frame_pointer;
>  void* x86_return_address;
>  /* parameters */
>  int a;
>  int b;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>    return f2->d + f1->a + f1->c;
> }
> 
> 
> 
> int f2(f1_frame_t* f1)
> {
>  int d = f1->a + f1->b;
>  return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
> }
> 
> 
> int F1(int a, int b)
> {
>  int c = a + b;
>  return f2((f1_frame_t*)&c);
> }
> 
> 
> This should be easily adapted to any function call convention/sequence.
> e.g. even if parameters are passed in registers.
> 
> 
> And for that matter, why don't we just transform it to be like this?
>  With the goal of reducing/eliminating gcc patches?
> 
> 
> Am I missing something?
> 
> 
> This form doesn't work?
> 
> 
> Isn't reasonably simple?
> 
> 
> Granted it might not be optimal. But it depends.
>  You know, you can copy in the local/parameter values, but then you have
>   to copy them out too. You can do analysis to show they aren't changed,
>   in which case no need to copy them out.
>  Similarly you can pass the parameters as separate parameters, by address
>   if they are ever changed.
> 
> 
> A portable transform couldn't depend on adjacency of locals and parameters.
> It would have to either copy the parameters into the frame_t, or their addresses.
> 
> 
> A portable form couldn't get the frame by taking the address of a "individual" local.
> 
> 
> Here is portable form:
> 
> 
> typedef struct {
>  int d;
>  f1_frame_t* f1;
> } f2_frame_t;
> 
> typedef struct {
>  int a;
>  int b;
>  int c;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2)
> {
>    return f2->d + f2->f1->a + f2->f1->c;
> }
> 
> int f2(f1_frame_t* f1)
> {
>  f2_frame_t f;
>  f.f1 = f1;
>  f.d = f1->a + f1->b;
>  return f1->a + f1->c + f3(&f);
> }
> 
> 
> int F1(int a, int b)
> {
>  f1_frame_t f;
>  f.a = a;
>  f.b = b;
>  f.c = a + b;
>  return f2(&f);
> }
> 
> 
> or:
> 
> 
> typedef struct {
>  int d;
> } f2_frame_t;
> 
> 
> typedef struct {
>  int a;
>  int b;
>  int c;
> } f1_frame_t;
> 
> 
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>    return f2->d + f1->a + f1->c;
> }
> 
> 
> int f2(f1_frame_t* f1)
> {
>  f2_frame_t f;
>  f.d = f1->a + f1->b;
>  return f1->a + f1->c + f3(&f, f1);
> }
> 
> 
> int F1(int a, int b)
> {
>  f1_frame_t f;
>  f.a = a;
>  f.b = b;
>  f.c = a + b;
>  return f2(&f);
> }
> 
> 
> 
> 
> - Jay
> 
> 
> 
> ----------------------------------------
>> Date: Thu, 20 May 2010 12:12:00 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> gcc even extends C with nested functions, and the support is there for that. We use it too.
>> 
>> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
>> you will ever see elsewhere. There are two static links. One is used for the first step
>> in following a static chain and points to the expected place in the target frame. The other
>> is used of subsequent steps in chain-following, and points to somewhere inside the target
>> frame that is dependent on the target procedure. It's the beginning of a subrecord where
>> all the nonlocally-referenced variables are collected. The second static link is also
>> located in there. All the nonlocally-referenced variables and parameters are duplicated
>> in there too.
>> 
>> I'm not sure I remembered these details exactly right. Maybe both links point to the
>> subrecord, but one is located at a traditional procedure-independent, fixed location
>> in the frame, while the second is located in the subrecord. Also, sometimes the first
>> static link value is kept in a register and never stored.
>> 
>> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
>> scheme that, I believe came from interaction between nested procedures and inlining them.
>> 
>> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>> 
>> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
>> with the current design of emitting debug info very early. The locations and target
>> offsets of these things aren't know until later, and m3gdb really needs to know them.
>> 
>> 
>> Jay K wrote:
>>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>>> Don't any of the other languages need it already?
>>> Ada? Pascal? Maybe the nested C function support?
>>> 
>>> - Jay
>>> 		 	   		  



From rcolebur at SCIRES.COM  Fri May 21 06:26:38 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 21 May 2010 00:26:38 -0400
Subject: [M3devel] m3core build failure
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>

I am getting a build error on Windows for m3core in HEAD branch:

"C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading

Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem.  Shouldn't this be "NT386" instead of "WIN32"?

Here is offending m3makefile:

C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
% Copyright (C) 1992, Digital Equipment Corporation
% All rights reserved.
% See the file COPYRIGHT for a full description.
%
% Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
%      modified on Wed Jun  9 17:25:51 PDT 1993 by harrison
%      modified on Thu May  6 12:11:46 PDT 1993 by muller
%      modified on Wed May  5 11:53:58 PDT 1993 by mjordan

include_dir ("Common")
include_dir (TARGET)
if equal(OS_TYPE, "WIN32")
  % long is 32bits even on 64bit Windows
  include("32BITS")
else
  include_dir (WORD_SIZE)
end

Regards,
Randy

________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100521/b1d89886/attachment-0002.html>

From jay.krell at cornell.edu  Fri May 21 06:44:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 04:44:25 +0000
Subject: [M3devel] m3core build failure
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>


Oops, it should be include_dir.
 
 
32BITS is deliberate -- 32bits has a 32bit long, 64bits has a 64bit long, all Win32 platforms, 32bit or 64bit, have a 32bit long.
 
 
We really should just not have long anywhere, but that might be difficult to achieve.
   The often purported portable meaning of "long", that is a pointer-sized, is false.
The pointer sized integers are INTEGER and Word.T, not "long".
 
 
 
 - Jay

________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Fri, 21 May 2010 00:26:38 -0400
> Subject: [M3devel] m3core build failure
>
>
>
>
>
>
>
>
>
>
>
>
> I am getting a build error on Windows for m3core in HEAD branch:
>
>
>
>
>
> "C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
>
>
> unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading
>
>
>
>
>
> Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem. Shouldn?t this be ?NT386? instead of ?WIN32??
>
>
>
>
>
> Here is offending m3makefile:
>
>
>
>
>
> C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
>
>
> % Copyright (C) 1992, Digital Equipment Corporation
>
>
> % All rights reserved.
>
>
> % See the file COPYRIGHT for a full description.
>
>
> %
>
>
> % Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
>
>
> % modified on Wed Jun 9 17:25:51 PDT 1993 by harrison
>
>
> % modified on Thu May 6 12:11:46 PDT 1993 by muller
>
>
> % modified on Wed May 5 11:53:58 PDT 1993 by mjordan
>
>
>
>
>
> include_dir ("Common")
>
>
> include_dir (TARGET)
>
>
> if equal(OS_TYPE, "WIN32")
>
>
> % long is 32bits even on 64bit Windows
>
>
> include("32BITS")
>
>
> else
>
>
> include_dir (WORD_SIZE)
>
>
> end
>
>
>
>
>
> Regards,
>
>
> Randy
>
>
>
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation.
> If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately
> and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>
>
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical
> data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data
> may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will
> comply with all applicable ITAR, EAR and embargo compliance requirements.
> 		 	   		  

From jay.krell at cornell.edu  Fri May 21 06:47:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 04:47:54 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, ,
	,,<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>,
	,,<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>,
	, , <2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, ,
	<4BF56D60.2000403@lcwb.coop>,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>
Message-ID: <COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>


Maybe we can/should transform into one of the forms I show and dispense with any gcc support?
At the cost of losing some "easy" optimization..of nested functions?
  "easy" as in, occurs even without -O2, but might occur with -O2?
 
 
I know what you mean -- NT386 passes the static link in ecx.
This is "ok" because in C++ the "this" pointer is passed in ecx.
 
 
Passing it as "just" another parameter might be less efficient, but ok?
  And really, it'd only be less efficient on one architecture -- 32bit x86.
  And maybe not all x86s -- depending on if some ABIs have a register based calling convention.
 
 
We don't need any actual ABI-compatibility with anything here, do we?
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 22:22:46 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> That is the standard formulation, but different architectures have different optimised forms (passing static link in a register, etc.). In any case, gcc has its own weird way of doing things, which we mostly use, but from which we need a little extra support (hence the small amount of special tailoring).
>
> On 20 May 2010, at 21:43, Jay K wrote:
>
>>
>> Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
>>
>>
>> The static link is an extra parameter.
>> And, as such, also an extra local variable.
>> You only need one.
>> Each nesting level would follow another chain.
>> Or you can pass each nesting level as an extra parameter.
>> Or you can optimize and pass locals/parameters separately.
>> But there is an obvious straightforward non-optimized form. ?
>>
>>
>> Here, I worked it through:
>>
>>
>>
>> Why doesn't it just look something like this:
>>
>>
>> nested:
>>
>> void F1(int a, int b)
>> {
>> int c = a + b;
>>
>> int f2()
>> {
>> int d = a + b;
>>
>> int f3()
>> {
>> return d + a + c;
>> }
>>
>> return a + c + f3();
>> }
>>
>> return f2();
>> }
>>
>> not nested:
>>
>>
>> typedef struct {
>> /* locals */
>> int d;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> f1_frame_t* f1;
>> } f2_frame_t;
>>
>>
>> typedef struct {
>> /* locals */
>> int c;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> int a;
>> int b;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2)
>> {
>> return f2->d + f2->f1->a + f2->f1->c;
>> }
>>
>>
>> int f2(f1_frame_t* f1)
>> {
>> int d = f1->a + f1->b;
>> return f1->a + f1->c + f3((f2_frame_t*)&d);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> int c = a + b;
>> return f2((f1_frame_t*)&c);
>> }
>>
>>
>> or, alernatively, almost the same, pass each chain as another parameter:
>>
>>
>> typedef struct {
>> /* locals */
>> int d;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> } f2_frame_t;
>>
>>
>> typedef struct {
>> /* locals */
>> int c;
>> void* x86_frame_pointer;
>> void* x86_return_address;
>> /* parameters */
>> int a;
>> int b;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2, f1_frame_t* f1)
>> {
>> return f2->d + f1->a + f1->c;
>> }
>>
>>
>>
>> int f2(f1_frame_t* f1)
>> {
>> int d = f1->a + f1->b;
>> return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> int c = a + b;
>> return f2((f1_frame_t*)&c);
>> }
>>
>>
>> This should be easily adapted to any function call convention/sequence.
>> e.g. even if parameters are passed in registers.
>>
>>
>> And for that matter, why don't we just transform it to be like this?
>> With the goal of reducing/eliminating gcc patches?
>>
>>
>> Am I missing something?
>>
>>
>> This form doesn't work?
>>
>>
>> Isn't reasonably simple?
>>
>>
>> Granted it might not be optimal. But it depends.
>> You know, you can copy in the local/parameter values, but then you have
>> to copy them out too. You can do analysis to show they aren't changed,
>> in which case no need to copy them out.
>> Similarly you can pass the parameters as separate parameters, by address
>> if they are ever changed.
>>
>>
>> A portable transform couldn't depend on adjacency of locals and parameters.
>> It would have to either copy the parameters into the frame_t, or their addresses.
>>
>>
>> A portable form couldn't get the frame by taking the address of a "individual" local.
>>
>>
>> Here is portable form:
>>
>>
>> typedef struct {
>> int d;
>> f1_frame_t* f1;
>> } f2_frame_t;
>>
>> typedef struct {
>> int a;
>> int b;
>> int c;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2)
>> {
>> return f2->d + f2->f1->a + f2->f1->c;
>> }
>>
>> int f2(f1_frame_t* f1)
>> {
>> f2_frame_t f;
>> f.f1 = f1;
>> f.d = f1->a + f1->b;
>> return f1->a + f1->c + f3(&f);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> f1_frame_t f;
>> f.a = a;
>> f.b = b;
>> f.c = a + b;
>> return f2(&f);
>> }
>>
>>
>> or:
>>
>>
>> typedef struct {
>> int d;
>> } f2_frame_t;
>>
>>
>> typedef struct {
>> int a;
>> int b;
>> int c;
>> } f1_frame_t;
>>
>>
>> int f3(f2_frame_t* f2, f1_frame_t* f1)
>> {
>> return f2->d + f1->a + f1->c;
>> }
>>
>>
>> int f2(f1_frame_t* f1)
>> {
>> f2_frame_t f;
>> f.d = f1->a + f1->b;
>> return f1->a + f1->c + f3(&f, f1);
>> }
>>
>>
>> int F1(int a, int b)
>> {
>> f1_frame_t f;
>> f.a = a;
>> f.b = b;
>> f.c = a + b;
>> return f2(&f);
>> }
>>
>>
>>
>>
>> - Jay
>>
>>
>>
>> ----------------------------------------
>>> Date: Thu, 20 May 2010 12:12:00 -0500
>>> From: rodney_bates at lcwb.coop
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>> gcc even extends C with nested functions, and the support is there for that. We use it too.
>>>
>>> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
>>> you will ever see elsewhere. There are two static links. One is used for the first step
>>> in following a static chain and points to the expected place in the target frame. The other
>>> is used of subsequent steps in chain-following, and points to somewhere inside the target
>>> frame that is dependent on the target procedure. It's the beginning of a subrecord where
>>> all the nonlocally-referenced variables are collected. The second static link is also
>>> located in there. All the nonlocally-referenced variables and parameters are duplicated
>>> in there too.
>>>
>>> I'm not sure I remembered these details exactly right. Maybe both links point to the
>>> subrecord, but one is located at a traditional procedure-independent, fixed location
>>> in the frame, while the second is located in the subrecord. Also, sometimes the first
>>> static link value is kept in a register and never stored.
>>>
>>> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
>>> scheme that, I believe came from interaction between nested procedures and inlining them.
>>>
>>> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>>>
>>> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
>>> with the current design of emitting debug info very early. The locations and target
>>> offsets of these things aren't know until later, and m3gdb really needs to know them.
>>>
>>>
>>> Jay K wrote:
>>>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>>>> Don't any of the other languages need it already?
>>>> Ada? Pascal? Maybe the nested C function support?
>>>>
>>>> - Jay
>>>>
> 		 	   		  

From rcolebur at SCIRES.COM  Fri May 21 07:00:17 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Fri, 21 May 2010 01:00:17 -0400
Subject: [M3devel] m3core build failure
In-Reply-To: <COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>
References: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>
	<COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>
Message-ID: <DBC0A6E744573F4FA5BF013793743B8711C191D33D@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

Thanks for the reply.

I don't think that is all that is wrong.  I changed to "include_dir", but now I am getting other errors.  For example:

new source -> compiling UnixC.c
cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
Oi -c ..\\src\\unix\\Common\\UnixC.c
UnixC.c
..\\src\\unix\\Common\\UnixC.c(95) : error C2375: 'Unix__open' : redefinition; d
ifferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(329) : see declaration of 'Un
ix__open'
..\\src\\unix\\Common\\UnixC.c(96) : error C2375: 'Unix__umask' : redefinition;
different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(337) : see declaration of 'Un
ix__umask'
..\\src\\unix\\Common\\UnixC.c(97) : error C2375: 'Unix__chmod' : redefinition;
different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(357) : see declaration of 'Un
ix__chmod'
..\\src\\unix\\Common\\UnixC.c(98) : error C2375: 'Unix__creat' : redefinition;
different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(361) : see declaration of 'Un
ix__creat'
..\\src\\unix\\Common\\UnixC.c(99) : error C2375: 'Unix__dup' : redefinition; di
fferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(362) : see declaration of 'Un
ix__dup'
  compile_c => 2
C compiler failed compiling: ..\src\unix\Common\UnixC.c
new source -> compiling Uin.c
cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
Oi -c ..\\src\\unix\\Common\\Uin.c
Uin.c
..\\src\\unix\\Common\\Uin.c(14) : error C2375: 'Uin__ntohl' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(364) : see declaration of 'Ui
n__ntohl'
..\\src\\unix\\Common\\Uin.c(15) : error C2375: 'Uin__ntohs' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(365) : see declaration of 'Ui
n__ntohs'
..\\src\\unix\\Common\\Uin.c(16) : error C2375: 'Uin__htonl' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(366) : see declaration of 'Ui
n__htonl'
..\\src\\unix\\Common\\Uin.c(17) : error C2375: 'Uin__htons' : redefinition; dif
ferent linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(367) : see declaration of 'Ui
n__htons'
  compile_c => 2
C compiler failed compiling: ..\src\unix\Common\Uin.c
new source -> compiling Usocket.c
cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
Oi -c ..\\src\\unix\\Common\\Usocket.c
Usocket.c
..\\src\\unix\\Common\\Usocket.c(65) : error C2375: 'Usocket__listen' : redefini
tion; different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(283) : see declaration of 'Us
ocket__listen'
..\\src\\unix\\Common\\Usocket.c(66) : error C2375: 'Usocket__shutdown' : redefi
nition; different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(284) : see declaration of 'Us
ocket__shutdown'
..\\src\\unix\\Common\\Usocket.c(67) : error C2375: 'Usocket__socket' : redefini
tion; different linkage
        C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(285) : see declaration of 'Us
ocket__socket'
  compile_c => 2
C compiler failed compiling: ..\src\unix\Common\Usocket.c
compilation failed => not building library "m3core.lib"
Fatal Error: package build failed

Regards,
Randy

-----Original Message-----
From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Friday, May 21, 2010 12:44 AM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] m3core build failure


Oops, it should be include_dir.


32BITS is deliberate -- 32bits has a 32bit long, 64bits has a 64bit long, all Win32 platforms, 32bit or 64bit, have a 32bit long.


We really should just not have long anywhere, but that might be difficult to achieve.
   The often purported portable meaning of "long", that is a pointer-sized, is false.
The pointer sized integers are INTEGER and Word.T, not "long".



 - Jay

________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Fri, 21 May 2010 00:26:38 -0400
> Subject: [M3devel] m3core build failure
>
>
>
>
>
>
>
>
>
>
>
>
> I am getting a build error on Windows for m3core in HEAD branch:
>
>
>
>
>
> "C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
>
>
> unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading
>
>
>
>
>
> Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem. Shouldn't this be "NT386" instead of "WIN32"?
>
>
>
>
>
> Here is offending m3makefile:
>
>
>
>
>
> C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
>
>
> % Copyright (C) 1992, Digital Equipment Corporation
>
>
> % All rights reserved.
>
>
> % See the file COPYRIGHT for a full description.
>
>
> %
>
>
> % Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
>
>
> % modified on Wed Jun 9 17:25:51 PDT 1993 by harrison
>
>
> % modified on Thu May 6 12:11:46 PDT 1993 by muller
>
>
> % modified on Wed May 5 11:53:58 PDT 1993 by mjordan
>
>
>
>
>
> include_dir ("Common")
>
>
> include_dir (TARGET)
>
>
> if equal(OS_TYPE, "WIN32")
>
>
> % long is 32bits even on 64bit Windows
>
>
> include("32BITS")
>
>
> else
>
>
> include_dir (WORD_SIZE)
>
>
> end
>
>
>
>
>
> Regards,
>
>
> Randy
>
>
>
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation.
> If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately
> and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>
>
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical
> data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data
> may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will
> comply with all applicable ITAR, EAR and embargo compliance requirements.
>

CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s).  This email may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.


From jay.krell at cornell.edu  Fri May 21 07:11:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 05:11:07 +0000
Subject: [M3devel] m3core build failure
In-Reply-To: <DBC0A6E744573F4FA5BF013793743B8711C191D33D@ATLEX02-SRV.SCIRES.LOCAL>
References: <DBC0A6E744573F4FA5BF013793743B8711C191D33C@ATLEX02-SRV.SCIRES.LOCAL>,
	<COL101-W2031446EC4A0A51BB7F47FE6E40@phx.gbl>,
	<DBC0A6E744573F4FA5BF013793743B8711C191D33D@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W31CE7568078110BBF4309AE6E40@phx.gbl>


I'll fix it later. Anything unix/common that doesn't compile for Win32, you can if out, even the whole directory. They aren't used currently.
 
 
 - Jay

----------------------------------------
> From: rcolebur at SCIRES.COM
> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> Date: Fri, 21 May 2010 01:00:17 -0400
> Subject: Re: [M3devel] m3core build failure
>
> Jay:
>
> Thanks for the reply.
>
> I don't think that is all that is wrong. I changed to "include_dir", but now I am getting other errors. For example:
>
> new source -> compiling UnixC.c
> cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
> n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
> on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
> src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
> Oi -c ..\\src\\unix\\Common\\UnixC.c
> UnixC.c
> ..\\src\\unix\\Common\\UnixC.c(95) : error C2375: 'Unix__open' : redefinition; d
> ifferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(329) : see declaration of 'Un
> ix__open'
> ..\\src\\unix\\Common\\UnixC.c(96) : error C2375: 'Unix__umask' : redefinition;
> different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(337) : see declaration of 'Un
> ix__umask'
> ..\\src\\unix\\Common\\UnixC.c(97) : error C2375: 'Unix__chmod' : redefinition;
> different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(357) : see declaration of 'Un
> ix__chmod'
> ..\\src\\unix\\Common\\UnixC.c(98) : error C2375: 'Unix__creat' : redefinition;
> different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(361) : see declaration of 'Un
> ix__creat'
> ..\\src\\unix\\Common\\UnixC.c(99) : error C2375: 'Unix__dup' : redefinition; di
> fferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(362) : see declaration of 'Un
> ix__dup'
> compile_c => 2
> C compiler failed compiling: ..\src\unix\Common\UnixC.c
> new source -> compiling Uin.c
> cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
> n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
> on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
> src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
> Oi -c ..\\src\\unix\\Common\\Uin.c
> Uin.c
> ..\\src\\unix\\Common\\Uin.c(14) : error C2375: 'Uin__ntohl' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(364) : see declaration of 'Ui
> n__ntohl'
> ..\\src\\unix\\Common\\Uin.c(15) : error C2375: 'Uin__ntohs' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(365) : see declaration of 'Ui
> n__ntohs'
> ..\\src\\unix\\Common\\Uin.c(16) : error C2375: 'Uin__htonl' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(366) : see declaration of 'Ui
> n__htonl'
> ..\\src\\unix\\Common\\Uin.c(17) : error C2375: 'Uin__htons' : redefinition; dif
> ferent linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(367) : see declaration of 'Ui
> n__htons'
> compile_c => 2
> C compiler failed compiling: ..\src\unix\Common\Uin.c
> new source -> compiling Usocket.c
> cl.exe -nologo -DWIN32 -Zl -I../src/unix/Common -I../src -I../src/Csupport/Commo
> n -I../src/Csupport/little-endian -I../src/Csupport/libgcc -I../src/runtime/comm
> on -I../src/runtime/WIN32 -I../src/runtime/ex_frame -I../src/thread/Common -I../
> src/thread/WIN32 -I../src/win32 -I../src/unix/Common -I../src/C/Common -Z7 -MD -
> Oi -c ..\\src\\unix\\Common\\Usocket.c
> Usocket.c
> ..\\src\\unix\\Common\\Usocket.c(65) : error C2375: 'Usocket__listen' : redefini
> tion; different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(283) : see declaration of 'Us
> ocket__listen'
> ..\\src\\unix\\Common\\Usocket.c(66) : error C2375: 'Usocket__shutdown' : redefi
> nition; different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(284) : see declaration of 'Us
> ocket__shutdown'
> ..\\src\\unix\\Common\\Usocket.c(67) : error C2375: 'Usocket__socket' : redefini
> tion; different linkage
> C:\cm3\Sandbox\m3-libs\m3core\src\m3core.h(285) : see declaration of 'Us
> ocket__socket'
> compile_c => 2
> C compiler failed compiling: ..\src\unix\Common\Usocket.c
> compilation failed => not building library "m3core.lib"
> Fatal Error: package build failed
>
> Regards,
> Randy
>
> -----Original Message-----
> From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
> Sent: Friday, May 21, 2010 12:44 AM
> To: Coleburn, Randy; m3devel
> Subject: RE: [M3devel] m3core build failure
>
>
> Oops, it should be include_dir.
>
>
> 32BITS is deliberate -- 32bits has a 32bit long, 64bits has a 64bit long, all Win32 platforms, 32bit or 64bit, have a 32bit long.
>
>
> We really should just not have long anywhere, but that might be difficult to achieve.
> The often purported portable meaning of "long", that is a pointer-sized, is false.
> The pointer sized integers are INTEGER and Word.T, not "long".
>
>
>
> - Jay
>
> ________________________________
>> From: rcolebur at SCIRES.COM
>> To: m3devel at elegosoft.com
>> Date: Fri, 21 May 2010 00:26:38 -0400
>> Subject: [M3devel] m3core build failure
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> I am getting a build error on Windows for m3core in HEAD branch:
>>
>>
>>
>>
>>
>> "C:\cm3\Sandbox\m3-libs\m3core\src\C\m3makefile", line 14: quake runtime error:
>>
>>
>> unable to open "C:\cm3\Sandbox\m3-libs\m3core\src\C\32BITS" for reading
>>
>>
>>
>>
>>
>> Suspect the if equal(OS_TYPE, "WIN32") include ("32BITS") is the problem. Shouldn't this be "NT386" instead of "WIN32"?
>>
>>
>>
>>
>>
>> Here is offending m3makefile:
>>
>>
>>
>>
>>
>> C:\cm3\Sandbox\m3-libs\m3core\src\C>type m3makefile
>>
>>
>> % Copyright (C) 1992, Digital Equipment Corporation
>>
>>
>> % All rights reserved.
>>
>>
>> % See the file COPYRIGHT for a full description.
>>
>>
>> %
>>
>>
>> % Last modified on Fri Aug 13 10:38:35 PDT 1993 by kalsow
>>
>>
>> % modified on Wed Jun 9 17:25:51 PDT 1993 by harrison
>>
>>
>> % modified on Thu May 6 12:11:46 PDT 1993 by muller
>>
>>
>> % modified on Wed May 5 11:53:58 PDT 1993 by mjordan
>>
>>
>>
>>
>>
>> include_dir ("Common")
>>
>>
>> include_dir (TARGET)
>>
>>
>> if equal(OS_TYPE, "WIN32")
>>
>>
>> % long is 32bits even on 64bit Windows
>>
>>
>> include("32BITS")
>>
>>
>> else
>>
>>
>> include_dir (WORD_SIZE)
>>
>>
>> end
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>> Randy
>>
>>
>>
>>
>> ________________________________
>>
>> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation.
>> If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately
>> and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>>
>>
>>
>> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical
>> data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data
>> may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will
>> comply with all applicable ITAR, EAR and embargo compliance requirements.
>>
>
> CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.
>
> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. 		 	   		  

From mika at async.async.caltech.edu  Fri May 21 07:37:56 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 20 May 2010 22:37:56 -0700
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl> 
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, ,
	<4BF56D60.2000403@lcwb.coop>,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>
Message-ID: <20100521053756.D74951A2094@async.async.caltech.edu>


As I recall it the "Dragon Book" has a whole section on this topic of
nested functions in Pascal.  Including Dijkstra's "display".  I'm not
an expert, just remember reading it.  Wirth also talks about it in his
"Good Ideas, Through the Looking Glass" (where he says the display
might be a pessimization).

     Mika

Jay K writes:
>
>Maybe we can/should transform into one of the forms I show and dispense wit=
>h any gcc support?
>At the cost of losing some "easy" optimization..of nested functions?
>  "easy" as in=2C occurs even without -O2=2C but might occur with -O2?
>=20
>=20
>I know what you mean -- NT386 passes the static link in ecx.
>This is "ok" because in C++ the "this" pointer is passed in ecx.
>=20
>=20
>Passing it as "just" another parameter might be less efficient=2C but ok?
>  And really=2C it'd only be less efficient on one architecture -- 32bit x8=
>6.
>  And maybe not all x86s -- depending on if some ABIs have a register based=
> calling convention.
>=20
>=20
>We don't need any actual ABI-compatibility with anything here=2C do we?
>=20
>=20
> - Jay
>
>
>----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu=2C 20 May 2010 22:22:46 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>> That is the standard formulation=2C but different architectures have diff=
>erent optimised forms (passing static link in a register=2C etc.). In any c=
>ase=2C gcc has its own weird way of doing things=2C which we mostly use=2C =
>but from which we need a little extra support (hence the small amount of sp=
>ecial tailoring).
>>
>> On 20 May 2010=2C at 21:43=2C Jay K wrote:
>>
>>>
>>> Wierd. To me the model to follow is almost obvious. It should be obvious=
> to everyone and implemented the way I have in mind. :)
>>>
>>>
>>> The static link is an extra parameter.
>>> And=2C as such=2C also an extra local variable.
>>> You only need one.
>>> Each nesting level would follow another chain.
>>> Or you can pass each nesting level as an extra parameter.
>>> Or you can optimize and pass locals/parameters separately.
>>> But there is an obvious straightforward non-optimized form. ?
>>>
>>>
>>> Here=2C I worked it through:
>>>
>>>
>>>
>>> Why doesn't it just look something like this:
>>>
>>>
>>> nested:
>>>
>>> void F1(int a=2C int b)
>>> {
>>> int c =3D a + b=3B
>>>
>>> int f2()
>>> {
>>> int d =3D a + b=3B
>>>
>>> int f3()
>>> {
>>> return d + a + c=3B
>>> }
>>>
>>> return a + c + f3()=3B
>>> }
>>>
>>> return f2()=3B
>>> }
>>>
>>> not nested:
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int d=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> f1_frame_t* f1=3B
>>> } f2_frame_t=3B
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int c=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> int a=3B
>>> int b=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2)
>>> {
>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>> }
>>>
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> int d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> int c =3D a + b=3B
>>> return f2((f1_frame_t*)&c)=3B
>>> }
>>>
>>>
>>> or=2C alernatively=2C almost the same=2C pass each chain as another para=
>meter:
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int d=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> } f2_frame_t=3B
>>>
>>>
>>> typedef struct {
>>> /* locals */
>>> int c=3B
>>> void* x86_frame_pointer=3B
>>> void* x86_return_address=3B
>>> /* parameters */
>>> int a=3B
>>> int b=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>> {
>>> return f2->d + f1->a + f1->c=3B
>>> }
>>>
>>>
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> int d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3((f2_frame_t*)&d=2C f1)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> int c =3D a + b=3B
>>> return f2((f1_frame_t*)&c)=3B
>>> }
>>>
>>>
>>> This should be easily adapted to any function call convention/sequence.
>>> e.g. even if parameters are passed in registers.
>>>
>>>
>>> And for that matter=2C why don't we just transform it to be like this?
>>> With the goal of reducing/eliminating gcc patches?
>>>
>>>
>>> Am I missing something?
>>>
>>>
>>> This form doesn't work?
>>>
>>>
>>> Isn't reasonably simple?
>>>
>>>
>>> Granted it might not be optimal. But it depends.
>>> You know=2C you can copy in the local/parameter values=2C but then you h=
>ave
>>> to copy them out too. You can do analysis to show they aren't changed=2C
>>> in which case no need to copy them out.
>>> Similarly you can pass the parameters as separate parameters=2C by addre=
>ss
>>> if they are ever changed.
>>>
>>>
>>> A portable transform couldn't depend on adjacency of locals and paramete=
>rs.
>>> It would have to either copy the parameters into the frame_t=2C or their=
> addresses.
>>>
>>>
>>> A portable form couldn't get the frame by taking the address of a "indiv=
>idual" local.
>>>
>>>
>>> Here is portable form:
>>>
>>>
>>> typedef struct {
>>> int d=3B
>>> f1_frame_t* f1=3B
>>> } f2_frame_t=3B
>>>
>>> typedef struct {
>>> int a=3B
>>> int b=3B
>>> int c=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2)
>>> {
>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>> }
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> f2_frame_t f=3B
>>> f.f1 =3D f1=3B
>>> f.d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3(&f)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> f1_frame_t f=3B
>>> f.a =3D a=3B
>>> f.b =3D b=3B
>>> f.c =3D a + b=3B
>>> return f2(&f)=3B
>>> }
>>>
>>>
>>> or:
>>>
>>>
>>> typedef struct {
>>> int d=3B
>>> } f2_frame_t=3B
>>>
>>>
>>> typedef struct {
>>> int a=3B
>>> int b=3B
>>> int c=3B
>>> } f1_frame_t=3B
>>>
>>>
>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>> {
>>> return f2->d + f1->a + f1->c=3B
>>> }
>>>
>>>
>>> int f2(f1_frame_t* f1)
>>> {
>>> f2_frame_t f=3B
>>> f.d =3D f1->a + f1->b=3B
>>> return f1->a + f1->c + f3(&f=2C f1)=3B
>>> }
>>>
>>>
>>> int F1(int a=2C int b)
>>> {
>>> f1_frame_t f=3B
>>> f.a =3D a=3B
>>> f.b =3D b=3B
>>> f.c =3D a + b=3B
>>> return f2(&f)=3B
>>> }
>>>
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Date: Thu=2C 20 May 2010 12:12:00 -0500
>>>> From: rodney_bates at lcwb.coop
>>>> To: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>
>>>> gcc even extends C with nested functions=2C and the support is there fo=
>r that. We use it too.
>>>>
>>>> Beware: The runtime model is=2C IMO=2C bizarre. Definitely counterintui=
>tive and unlike anything
>>>> you will ever see elsewhere. There are two static links. One is used fo=
>r the first step
>>>> in following a static chain and points to the expected place in the tar=
>get frame. The other
>>>> is used of subsequent steps in chain-following=2C and points to somewhe=
>re inside the target
>>>> frame that is dependent on the target procedure. It's the beginning of =
>a subrecord where
>>>> all the nonlocally-referenced variables are collected. The second stati=
>c link is also
>>>> located in there. All the nonlocally-referenced variables and parameter=
>s are duplicated
>>>> in there too.
>>>>
>>>> I'm not sure I remembered these details exactly right. Maybe both links=
> point to the
>>>> subrecord=2C but one is located at a traditional procedure-independent=
>=2C fixed location
>>>> in the frame=2C while the second is located in the subrecord. Also=2C s=
>ometimes the first
>>>> static link value is kept in a register and never stored.
>>>>
>>>> What this all apparently accomplishes is simplifying an "insanely compl=
>icated" _compile-time_
>>>> scheme that=2C I believe came from interaction between nested procedure=
>s and inlining them.
>>>>
>>>> But it's at the cost of what I would call an insanely complicated _runt=
>ime_ scheme.
>>>>
>>>> It undermined m3gdb's handling of static links=2C and I don't think it'=
>s possible to fix
>>>> with the current design of emitting debug info very early. The location=
>s and target
>>>> offsets of these things aren't know until later=2C and m3gdb really nee=
>ds to know them.
>>>>
>>>>
>>>> Jay K wrote:
>>>>> What I meant regarding "static chain" was more like "does gcc already =
>have support that we can use".
>>>>> Don't any of the other languages need it already?
>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>
>>>>> - Jay
>>>>>
>> 		 	   		  =


From jay.krell at cornell.edu  Fri May 21 08:41:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 06:41:42 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <20100521053756.D74951A2094@async.async.caltech.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , ,
	,,<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	,,<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	,,<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	,,<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	, , <4BF56D60.2000403@lcwb.coop>, ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>,
	<20100521053756.D74951A2094@async.async.caltech.edu>
Message-ID: <COL101-W62B5841AA922ECC333168E6E40@phx.gbl>


Thanks for the reference!
 
search for "Good Ideas, Through the Looking Glass"
finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_origFig.pdf"
(I don't need to provide the link really.)
 
 - Jay

----------------------------------------
> To: jay.krell at cornell.edu
> Date: Thu, 20 May 2010 22:37:56 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
>
> As I recall it the "Dragon Book" has a whole section on this topic of
> nested functions in Pascal. Including Dijkstra's "display". I'm not
> an expert, just remember reading it. Wirth also talks about it in his
> "Good Ideas, Through the Looking Glass" (where he says the display
> might be a pessimization).
>
> Mika
>
> Jay K writes:
>>
>>Maybe we can/should transform into one of the forms I show and dispense wit=
>>h any gcc support?
>>At the cost of losing some "easy" optimization..of nested functions?
>> "easy" as in=2C occurs even without -O2=2C but might occur with -O2?
>>=20
>>=20
>>I know what you mean -- NT386 passes the static link in ecx.
>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>=20
>>=20
>>Passing it as "just" another parameter might be less efficient=2C but ok?
>> And really=2C it'd only be less efficient on one architecture -- 32bit x8=
>>6.
>> And maybe not all x86s -- depending on if some ABIs have a register based=
>> calling convention.
>>=20
>>=20
>>We don't need any actual ABI-compatibility with anything here=2C do we?
>>=20
>>=20
>> - Jay
>>
>>
>>----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Thu=2C 20 May 2010 22:22:46 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>> That is the standard formulation=2C but different architectures have diff=
>>erent optimised forms (passing static link in a register=2C etc.). In any c=
>>ase=2C gcc has its own weird way of doing things=2C which we mostly use=2C =
>>but from which we need a little extra support (hence the small amount of sp=
>>ecial tailoring).
>>>
>>> On 20 May 2010=2C at 21:43=2C Jay K wrote:
>>>
>>>>
>>>> Wierd. To me the model to follow is almost obvious. It should be obvious=
>> to everyone and implemented the way I have in mind. :)
>>>>
>>>>
>>>> The static link is an extra parameter.
>>>> And=2C as such=2C also an extra local variable.
>>>> You only need one.
>>>> Each nesting level would follow another chain.
>>>> Or you can pass each nesting level as an extra parameter.
>>>> Or you can optimize and pass locals/parameters separately.
>>>> But there is an obvious straightforward non-optimized form. ?
>>>>
>>>>
>>>> Here=2C I worked it through:
>>>>
>>>>
>>>>
>>>> Why doesn't it just look something like this:
>>>>
>>>>
>>>> nested:
>>>>
>>>> void F1(int a=2C int b)
>>>> {
>>>> int c =3D a + b=3B
>>>>
>>>> int f2()
>>>> {
>>>> int d =3D a + b=3B
>>>>
>>>> int f3()
>>>> {
>>>> return d + a + c=3B
>>>> }
>>>>
>>>> return a + c + f3()=3B
>>>> }
>>>>
>>>> return f2()=3B
>>>> }
>>>>
>>>> not nested:
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int d=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> f1_frame_t* f1=3B
>>>> } f2_frame_t=3B
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int c=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> int a=3B
>>>> int b=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2)
>>>> {
>>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>>> }
>>>>
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> int d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> int c =3D a + b=3B
>>>> return f2((f1_frame_t*)&c)=3B
>>>> }
>>>>
>>>>
>>>> or=2C alernatively=2C almost the same=2C pass each chain as another para=
>>meter:
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int d=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> } f2_frame_t=3B
>>>>
>>>>
>>>> typedef struct {
>>>> /* locals */
>>>> int c=3B
>>>> void* x86_frame_pointer=3B
>>>> void* x86_return_address=3B
>>>> /* parameters */
>>>> int a=3B
>>>> int b=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>>> {
>>>> return f2->d + f1->a + f1->c=3B
>>>> }
>>>>
>>>>
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> int d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=2C f1)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> int c =3D a + b=3B
>>>> return f2((f1_frame_t*)&c)=3B
>>>> }
>>>>
>>>>
>>>> This should be easily adapted to any function call convention/sequence.
>>>> e.g. even if parameters are passed in registers.
>>>>
>>>>
>>>> And for that matter=2C why don't we just transform it to be like this?
>>>> With the goal of reducing/eliminating gcc patches?
>>>>
>>>>
>>>> Am I missing something?
>>>>
>>>>
>>>> This form doesn't work?
>>>>
>>>>
>>>> Isn't reasonably simple?
>>>>
>>>>
>>>> Granted it might not be optimal. But it depends.
>>>> You know=2C you can copy in the local/parameter values=2C but then you h=
>>ave
>>>> to copy them out too. You can do analysis to show they aren't changed=2C
>>>> in which case no need to copy them out.
>>>> Similarly you can pass the parameters as separate parameters=2C by addre=
>>ss
>>>> if they are ever changed.
>>>>
>>>>
>>>> A portable transform couldn't depend on adjacency of locals and paramete=
>>rs.
>>>> It would have to either copy the parameters into the frame_t=2C or their=
>> addresses.
>>>>
>>>>
>>>> A portable form couldn't get the frame by taking the address of a "indiv=
>>idual" local.
>>>>
>>>>
>>>> Here is portable form:
>>>>
>>>>
>>>> typedef struct {
>>>> int d=3B
>>>> f1_frame_t* f1=3B
>>>> } f2_frame_t=3B
>>>>
>>>> typedef struct {
>>>> int a=3B
>>>> int b=3B
>>>> int c=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2)
>>>> {
>>>> return f2->d + f2->f1->a + f2->f1->c=3B
>>>> }
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> f2_frame_t f=3B
>>>> f.f1 =3D f1=3B
>>>> f.d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3(&f)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> f1_frame_t f=3B
>>>> f.a =3D a=3B
>>>> f.b =3D b=3B
>>>> f.c =3D a + b=3B
>>>> return f2(&f)=3B
>>>> }
>>>>
>>>>
>>>> or:
>>>>
>>>>
>>>> typedef struct {
>>>> int d=3B
>>>> } f2_frame_t=3B
>>>>
>>>>
>>>> typedef struct {
>>>> int a=3B
>>>> int b=3B
>>>> int c=3B
>>>> } f1_frame_t=3B
>>>>
>>>>
>>>> int f3(f2_frame_t* f2=2C f1_frame_t* f1)
>>>> {
>>>> return f2->d + f1->a + f1->c=3B
>>>> }
>>>>
>>>>
>>>> int f2(f1_frame_t* f1)
>>>> {
>>>> f2_frame_t f=3B
>>>> f.d =3D f1->a + f1->b=3B
>>>> return f1->a + f1->c + f3(&f=2C f1)=3B
>>>> }
>>>>
>>>>
>>>> int F1(int a=2C int b)
>>>> {
>>>> f1_frame_t f=3B
>>>> f.a =3D a=3B
>>>> f.b =3D b=3B
>>>> f.c =3D a + b=3B
>>>> return f2(&f)=3B
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Thu=2C 20 May 2010 12:12:00 -0500
>>>>> From: rodney_bates at lcwb.coop
>>>>> To: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>
>>>>> gcc even extends C with nested functions=2C and the support is there fo=
>>r that. We use it too.
>>>>>
>>>>> Beware: The runtime model is=2C IMO=2C bizarre. Definitely counterintui=
>>tive and unlike anything
>>>>> you will ever see elsewhere. There are two static links. One is used fo=
>>r the first step
>>>>> in following a static chain and points to the expected place in the tar=
>>get frame. The other
>>>>> is used of subsequent steps in chain-following=2C and points to somewhe=
>>re inside the target
>>>>> frame that is dependent on the target procedure. It's the beginning of =
>>a subrecord where
>>>>> all the nonlocally-referenced variables are collected. The second stati=
>>c link is also
>>>>> located in there. All the nonlocally-referenced variables and parameter=
>>s are duplicated
>>>>> in there too.
>>>>>
>>>>> I'm not sure I remembered these details exactly right. Maybe both links=
>> point to the
>>>>> subrecord=2C but one is located at a traditional procedure-independent=
>>=2C fixed location
>>>>> in the frame=2C while the second is located in the subrecord. Also=2C s=
>>ometimes the first
>>>>> static link value is kept in a register and never stored.
>>>>>
>>>>> What this all apparently accomplishes is simplifying an "insanely compl=
>>icated" _compile-time_
>>>>> scheme that=2C I believe came from interaction between nested procedure=
>>s and inlining them.
>>>>>
>>>>> But it's at the cost of what I would call an insanely complicated _runt=
>>ime_ scheme.
>>>>>
>>>>> It undermined m3gdb's handling of static links=2C and I don't think it'=
>>s possible to fix
>>>>> with the current design of emitting debug info very early. The location=
>>s and target
>>>>> offsets of these things aren't know until later=2C and m3gdb really nee=
>>ds to know them.
>>>>>
>>>>>
>>>>> Jay K wrote:
>>>>>> What I meant regarding "static chain" was more like "does gcc already =
>>have support that we can use".
>>>>>> Don't any of the other languages need it already?
>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>
>>>>>> - Jay
>>>>>>
>>> = 		 	   		  

From mika at async.async.caltech.edu  Fri May 21 08:45:22 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Thu, 20 May 2010 23:45:22 -0700
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W62B5841AA922ECC333168E6E40@phx.gbl> 
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, , ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, , ,
	<4BF56D60.2000403@lcwb.coop>, ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>,
	<20100521053756.D74951A2094@async.async.caltech.edu>
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>
Message-ID: <20100521064522.93AAC1A2094@async.async.caltech.edu>

The Dragon Book is 

Aho, Sethi, Ullman.  Compilers: Principles, Techniques, and Tools.
Addison-Wesley, 1988.  Chapter 7, esp. Sec. 7.4.

   Mika

Jay K writes:
>
>Thanks for the reference!
>=20
>search for "Good Ideas=2C Through the Looking Glass"
>finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_o=
>rigFig.pdf"
>(I don't need to provide the link really.)
>=20
> - Jay
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Thu=2C 20 May 2010 22:37:56 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>>
>> As I recall it the "Dragon Book" has a whole section on this topic of
>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>> an expert=2C just remember reading it. Wirth also talks about it in his
>> "Good Ideas=2C Through the Looking Glass" (where he says the display
>> might be a pessimization).
>>
>> Mika
>>
>> Jay K writes:
>>>
>>>Maybe we can/should transform into one of the forms I show and dispense w=
>it=3D
>>>h any gcc support?
>>>At the cost of losing some "easy" optimization..of nested functions?
>>> "easy" as in=3D2C occurs even without -O2=3D2C but might occur with -O2?
>>>=3D20
>>>=3D20
>>>I know what you mean -- NT386 passes the static link in ecx.
>>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>=3D20
>>>=3D20
>>>Passing it as "just" another parameter might be less efficient=3D2C but o=
>k?
>>> And really=3D2C it'd only be less efficient on one architecture -- 32bit=
> x8=3D
>>>6.
>>> And maybe not all x86s -- depending on if some ABIs have a register base=
>d=3D
>>> calling convention.
>>>=3D20
>>>=3D20
>>>We don't need any actual ABI-compatibility with anything here=3D2C do we?
>>>=3D20
>>>=3D20
>>> - Jay
>>>
>>>
>>>----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Thu=3D2C 20 May 2010 22:22:46 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>
>>>> That is the standard formulation=3D2C but different architectures have =
>diff=3D
>>>erent optimised forms (passing static link in a register=3D2C etc.). In a=
>ny c=3D
>>>ase=3D2C gcc has its own weird way of doing things=3D2C which we mostly u=
>se=3D2C =3D
>>>but from which we need a little extra support (hence the small amount of =
>sp=3D
>>>ecial tailoring).
>>>>
>>>> On 20 May 2010=3D2C at 21:43=3D2C Jay K wrote:
>>>>
>>>>>
>>>>> Wierd. To me the model to follow is almost obvious. It should be obvio=
>us=3D
>>> to everyone and implemented the way I have in mind. :)
>>>>>
>>>>>
>>>>> The static link is an extra parameter.
>>>>> And=3D2C as such=3D2C also an extra local variable.
>>>>> You only need one.
>>>>> Each nesting level would follow another chain.
>>>>> Or you can pass each nesting level as an extra parameter.
>>>>> Or you can optimize and pass locals/parameters separately.
>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>
>>>>>
>>>>> Here=3D2C I worked it through:
>>>>>
>>>>>
>>>>>
>>>>> Why doesn't it just look something like this:
>>>>>
>>>>>
>>>>> nested:
>>>>>
>>>>> void F1(int a=3D2C int b)
>>>>> {
>>>>> int c =3D3D a + b=3D3B
>>>>>
>>>>> int f2()
>>>>> {
>>>>> int d =3D3D a + b=3D3B
>>>>>
>>>>> int f3()
>>>>> {
>>>>> return d + a + c=3D3B
>>>>> }
>>>>>
>>>>> return a + c + f3()=3D3B
>>>>> }
>>>>>
>>>>> return f2()=3D3B
>>>>> }
>>>>>
>>>>> not nested:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int d=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> f1_frame_t* f1=3D3B
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int c=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2)
>>>>> {
>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> int c =3D3D a + b=3D3B
>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> or=3D2C alernatively=3D2C almost the same=3D2C pass each chain as anot=
>her para=3D
>>>meter:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int d=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> /* locals */
>>>>> int c=3D3B
>>>>> void* x86_frame_pointer=3D3B
>>>>> void* x86_return_address=3D3B
>>>>> /* parameters */
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>> {
>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D2C f1)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> int c =3D3D a + b=3D3B
>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> This should be easily adapted to any function call convention/sequence=
>.
>>>>> e.g. even if parameters are passed in registers.
>>>>>
>>>>>
>>>>> And for that matter=3D2C why don't we just transform it to be like thi=
>s?
>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>>
>>>>> This form doesn't work?
>>>>>
>>>>>
>>>>> Isn't reasonably simple?
>>>>>
>>>>>
>>>>> Granted it might not be optimal. But it depends.
>>>>> You know=3D2C you can copy in the local/parameter values=3D2C but then=
> you h=3D
>>>ave
>>>>> to copy them out too. You can do analysis to show they aren't changed=
>=3D2C
>>>>> in which case no need to copy them out.
>>>>> Similarly you can pass the parameters as separate parameters=3D2C by a=
>ddre=3D
>>>ss
>>>>> if they are ever changed.
>>>>>
>>>>>
>>>>> A portable transform couldn't depend on adjacency of locals and parame=
>te=3D
>>>rs.
>>>>> It would have to either copy the parameters into the frame_t=3D2C or t=
>heir=3D
>>> addresses.
>>>>>
>>>>>
>>>>> A portable form couldn't get the frame by taking the address of a "ind=
>iv=3D
>>>idual" local.
>>>>>
>>>>>
>>>>> Here is portable form:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> int d=3D3B
>>>>> f1_frame_t* f1=3D3B
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>> typedef struct {
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> int c=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2)
>>>>> {
>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>> }
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> f2_frame_t f=3D3B
>>>>> f.f1 =3D3D f1=3D3B
>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3(&f)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> f1_frame_t f=3D3B
>>>>> f.a =3D3D a=3D3B
>>>>> f.b =3D3D b=3D3B
>>>>> f.c =3D3D a + b=3D3B
>>>>> return f2(&f)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> or:
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> int d=3D3B
>>>>> } f2_frame_t=3D3B
>>>>>
>>>>>
>>>>> typedef struct {
>>>>> int a=3D3B
>>>>> int b=3D3B
>>>>> int c=3D3B
>>>>> } f1_frame_t=3D3B
>>>>>
>>>>>
>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>> {
>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int f2(f1_frame_t* f1)
>>>>> {
>>>>> f2_frame_t f=3D3B
>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>> return f1->a + f1->c + f3(&f=3D2C f1)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>> int F1(int a=3D2C int b)
>>>>> {
>>>>> f1_frame_t f=3D3B
>>>>> f.a =3D3D a=3D3B
>>>>> f.b =3D3D b=3D3B
>>>>> f.c =3D3D a + b=3D3B
>>>>> return f2(&f)=3D3B
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> Date: Thu=3D2C 20 May 2010 12:12:00 -0500
>>>>>> From: rodney_bates at lcwb.coop
>>>>>> To: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>
>>>>>> gcc even extends C with nested functions=3D2C and the support is ther=
>e fo=3D
>>>r that. We use it too.
>>>>>>
>>>>>> Beware: The runtime model is=3D2C IMO=3D2C bizarre. Definitely counte=
>rintui=3D
>>>tive and unlike anything
>>>>>> you will ever see elsewhere. There are two static links. One is used =
>fo=3D
>>>r the first step
>>>>>> in following a static chain and points to the expected place in the t=
>ar=3D
>>>get frame. The other
>>>>>> is used of subsequent steps in chain-following=3D2C and points to som=
>ewhe=3D
>>>re inside the target
>>>>>> frame that is dependent on the target procedure. It's the beginning o=
>f =3D
>>>a subrecord where
>>>>>> all the nonlocally-referenced variables are collected. The second sta=
>ti=3D
>>>c link is also
>>>>>> located in there. All the nonlocally-referenced variables and paramet=
>er=3D
>>>s are duplicated
>>>>>> in there too.
>>>>>>
>>>>>> I'm not sure I remembered these details exactly right. Maybe both lin=
>ks=3D
>>> point to the
>>>>>> subrecord=3D2C but one is located at a traditional procedure-independ=
>ent=3D
>>>=3D2C fixed location
>>>>>> in the frame=3D2C while the second is located in the subrecord. Also=
>=3D2C s=3D
>>>ometimes the first
>>>>>> static link value is kept in a register and never stored.
>>>>>>
>>>>>> What this all apparently accomplishes is simplifying an "insanely com=
>pl=3D
>>>icated" _compile-time_
>>>>>> scheme that=3D2C I believe came from interaction between nested proce=
>dure=3D
>>>s and inlining them.
>>>>>>
>>>>>> But it's at the cost of what I would call an insanely complicated _ru=
>nt=3D
>>>ime_ scheme.
>>>>>>
>>>>>> It undermined m3gdb's handling of static links=3D2C and I don't think=
> it'=3D
>>>s possible to fix
>>>>>> with the current design of emitting debug info very early. The locati=
>on=3D
>>>s and target
>>>>>> offsets of these things aren't know until later=3D2C and m3gdb really=
> nee=3D
>>>ds to know them.
>>>>>>
>>>>>>
>>>>>> Jay K wrote:
>>>>>>> What I meant regarding "static chain" was more like "does gcc alread=
>y =3D
>>>have support that we can use".
>>>>>>> Don't any of the other languages need it already?
>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>> =3D 		 	   		  =


From jay.krell at cornell.edu  Fri May 21 09:41:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 07:41:46 +0000
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <20100521064522.93AAC1A2094@async.async.caltech.edu>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , ,
	,,<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , ,
	,,<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , ,
	,,<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, ,
	,,<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, ,
	,,<4BF56D60.2000403@lcwb.coop>,
	,,<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>,
	, , <AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>, ,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>, ,
	<20100521053756.D74951A2094@async.async.caltech.edu>,
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>,
	<20100521064522.93AAC1A2094@async.async.caltech.edu>
Message-ID: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>


Of course. I tried to read it as a teenager and got stuck on the automata stuff.
 
 
Wirth isn't 100% clear to me.
 He describes my two schemes.
 I think he throws out the second as an unimportant optimization.
 He criticizes the first as inefficient, granted.
 What I don't get is the static link in addition to the dynamic link.
 Perhaps I have not accounted for recursion.
 
 
Oh..I see..he is allowing to take the address of a nested function.
I didn't account for that.
I still don't understand all the arrow he draws for the static link, but
I do see that my scheme doesn't suffice.
Taking the address of a nested function..doesn't seem like a good idea.
Maybe I'm too C-minded.
 
 
My prototypical favorite Scheme example is:
 
 
(define (make-adder x)
   (define (add y) (+ x y))
   add)
 
 
(define add2 (make-adder 2))
(add2 3) => 5
 
 
but Modula-3 doesn't allow for that anyway..
 
Still, we make "closures": tuple{-1, function pointer, frame pointer}
before calling a pointer, we check if it points to -1, and if so
we call function pointer with frame pointer as the link.
 
 
And then I guess, you might have something like this?
 
 
 
int F1(int a, int b, int (*F)())
{
  int F2()
  {
    return a + b;
  }
 
  if (F != NULL)
   return F();
 
  return F1(a - 1, b - 1, &F2);
 
}
 
 
F(1, 2, NULL) => 3
 
 
Though that doesn't demonstrate the generality perhaps.
 
 
Taking the address of a nested function seems dubious.
 
 
My "favorite" bit of Schema:
 
(define (make-adder x)
   (define (add y) (+ x y))
   add)
 
 
(define add2 (make-adder 2))
 
(add2 3) => 3
 
 
But we don't allow that sort of thing -- frames are always stack allocated.
 
 
 
 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Thu, 20 May 2010 23:45:22 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc 4.5.0?
>
> The Dragon Book is
>
> Aho, Sethi, Ullman. Compilers: Principles, Techniques, and Tools.
> Addison-Wesley, 1988. Chapter 7, esp. Sec. 7.4.
>
> Mika
>
> Jay K writes:
>>
>>Thanks for the reference!
>>=20
>>search for "Good Ideas=2C Through the Looking Glass"
>>finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_o=
>>rigFig.pdf"
>>(I don't need to provide the link really.)
>>=20
>> - Jay
>>
>>----------------------------------------
>>> To: jay.krell at cornell.edu
>>> Date: Thu=2C 20 May 2010 22:37:56 -0700
>>> From: mika at async.async.caltech.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>
>>>
>>> As I recall it the "Dragon Book" has a whole section on this topic of
>>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>>> an expert=2C just remember reading it. Wirth also talks about it in his
>>> "Good Ideas=2C Through the Looking Glass" (where he says the display
>>> might be a pessimization).
>>>
>>> Mika
>>>
>>> Jay K writes:
>>>>
>>>>Maybe we can/should transform into one of the forms I show and dispense w=
>>it=3D
>>>>h any gcc support?
>>>>At the cost of losing some "easy" optimization..of nested functions?
>>>> "easy" as in=3D2C occurs even without -O2=3D2C but might occur with -O2?
>>>>=3D20
>>>>=3D20
>>>>I know what you mean -- NT386 passes the static link in ecx.
>>>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>>=3D20
>>>>=3D20
>>>>Passing it as "just" another parameter might be less efficient=3D2C but o=
>>k?
>>>> And really=3D2C it'd only be less efficient on one architecture -- 32bit=
>> x8=3D
>>>>6.
>>>> And maybe not all x86s -- depending on if some ABIs have a register base=
>>d=3D
>>>> calling convention.
>>>>=3D20
>>>>=3D20
>>>>We don't need any actual ABI-compatibility with anything here=3D2C do we?
>>>>=3D20
>>>>=3D20
>>>> - Jay
>>>>
>>>>
>>>>----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Thu=3D2C 20 May 2010 22:22:46 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>
>>>>> That is the standard formulation=3D2C but different architectures have =
>>diff=3D
>>>>erent optimised forms (passing static link in a register=3D2C etc.). In a=
>>ny c=3D
>>>>ase=3D2C gcc has its own weird way of doing things=3D2C which we mostly u=
>>se=3D2C =3D
>>>>but from which we need a little extra support (hence the small amount of =
>>sp=3D
>>>>ecial tailoring).
>>>>>
>>>>> On 20 May 2010=3D2C at 21:43=3D2C Jay K wrote:
>>>>>
>>>>>>
>>>>>> Wierd. To me the model to follow is almost obvious. It should be obvio=
>>us=3D
>>>> to everyone and implemented the way I have in mind. :)
>>>>>>
>>>>>>
>>>>>> The static link is an extra parameter.
>>>>>> And=3D2C as such=3D2C also an extra local variable.
>>>>>> You only need one.
>>>>>> Each nesting level would follow another chain.
>>>>>> Or you can pass each nesting level as an extra parameter.
>>>>>> Or you can optimize and pass locals/parameters separately.
>>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>>
>>>>>>
>>>>>> Here=3D2C I worked it through:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Why doesn't it just look something like this:
>>>>>>
>>>>>>
>>>>>> nested:
>>>>>>
>>>>>> void F1(int a=3D2C int b)
>>>>>> {
>>>>>> int c =3D3D a + b=3D3B
>>>>>>
>>>>>> int f2()
>>>>>> {
>>>>>> int d =3D3D a + b=3D3B
>>>>>>
>>>>>> int f3()
>>>>>> {
>>>>>> return d + a + c=3D3B
>>>>>> }
>>>>>>
>>>>>> return a + c + f3()=3D3B
>>>>>> }
>>>>>>
>>>>>> return f2()=3D3B
>>>>>> }
>>>>>>
>>>>>> not nested:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int d=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> f1_frame_t* f1=3D3B
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int c=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2)
>>>>>> {
>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> int c =3D3D a + b=3D3B
>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> or=3D2C alernatively=3D2C almost the same=3D2C pass each chain as anot=
>>her para=3D
>>>>meter:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int d=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> /* locals */
>>>>>> int c=3D3B
>>>>>> void* x86_frame_pointer=3D3B
>>>>>> void* x86_return_address=3D3B
>>>>>> /* parameters */
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>> {
>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D2C f1)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> int c =3D3D a + b=3D3B
>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> This should be easily adapted to any function call convention/sequence=
>>.
>>>>>> e.g. even if parameters are passed in registers.
>>>>>>
>>>>>>
>>>>>> And for that matter=3D2C why don't we just transform it to be like thi=
>>s?
>>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>>
>>>>>>
>>>>>> Am I missing something?
>>>>>>
>>>>>>
>>>>>> This form doesn't work?
>>>>>>
>>>>>>
>>>>>> Isn't reasonably simple?
>>>>>>
>>>>>>
>>>>>> Granted it might not be optimal. But it depends.
>>>>>> You know=3D2C you can copy in the local/parameter values=3D2C but then=
>> you h=3D
>>>>ave
>>>>>> to copy them out too. You can do analysis to show they aren't changed=
>>=3D2C
>>>>>> in which case no need to copy them out.
>>>>>> Similarly you can pass the parameters as separate parameters=3D2C by a=
>>ddre=3D
>>>>ss
>>>>>> if they are ever changed.
>>>>>>
>>>>>>
>>>>>> A portable transform couldn't depend on adjacency of locals and parame=
>>te=3D
>>>>rs.
>>>>>> It would have to either copy the parameters into the frame_t=3D2C or t=
>>heir=3D
>>>> addresses.
>>>>>>
>>>>>>
>>>>>> A portable form couldn't get the frame by taking the address of a "ind=
>>iv=3D
>>>>idual" local.
>>>>>>
>>>>>>
>>>>>> Here is portable form:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> int d=3D3B
>>>>>> f1_frame_t* f1=3D3B
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>> typedef struct {
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> int c=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2)
>>>>>> {
>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> f2_frame_t f=3D3B
>>>>>> f.f1 =3D3D f1=3D3B
>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3(&f)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> f1_frame_t f=3D3B
>>>>>> f.a =3D3D a=3D3B
>>>>>> f.b =3D3D b=3D3B
>>>>>> f.c =3D3D a + b=3D3B
>>>>>> return f2(&f)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> or:
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> int d=3D3B
>>>>>> } f2_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> typedef struct {
>>>>>> int a=3D3B
>>>>>> int b=3D3B
>>>>>> int c=3D3B
>>>>>> } f1_frame_t=3D3B
>>>>>>
>>>>>>
>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>> {
>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int f2(f1_frame_t* f1)
>>>>>> {
>>>>>> f2_frame_t f=3D3B
>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>> return f1->a + f1->c + f3(&f=3D2C f1)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int F1(int a=3D2C int b)
>>>>>> {
>>>>>> f1_frame_t f=3D3B
>>>>>> f.a =3D3D a=3D3B
>>>>>> f.b =3D3D b=3D3B
>>>>>> f.c =3D3D a + b=3D3B
>>>>>> return f2(&f)=3D3B
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> Date: Thu=3D2C 20 May 2010 12:12:00 -0500
>>>>>>> From: rodney_bates at lcwb.coop
>>>>>>> To: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>>
>>>>>>> gcc even extends C with nested functions=3D2C and the support is ther=
>>e fo=3D
>>>>r that. We use it too.
>>>>>>>
>>>>>>> Beware: The runtime model is=3D2C IMO=3D2C bizarre. Definitely counte=
>>rintui=3D
>>>>tive and unlike anything
>>>>>>> you will ever see elsewhere. There are two static links. One is used =
>>fo=3D
>>>>r the first step
>>>>>>> in following a static chain and points to the expected place in the t=
>>ar=3D
>>>>get frame. The other
>>>>>>> is used of subsequent steps in chain-following=3D2C and points to som=
>>ewhe=3D
>>>>re inside the target
>>>>>>> frame that is dependent on the target procedure. It's the beginning o=
>>f =3D
>>>>a subrecord where
>>>>>>> all the nonlocally-referenced variables are collected. The second sta=
>>ti=3D
>>>>c link is also
>>>>>>> located in there. All the nonlocally-referenced variables and paramet=
>>er=3D
>>>>s are duplicated
>>>>>>> in there too.
>>>>>>>
>>>>>>> I'm not sure I remembered these details exactly right. Maybe both lin=
>>ks=3D
>>>> point to the
>>>>>>> subrecord=3D2C but one is located at a traditional procedure-independ=
>>ent=3D
>>>>=3D2C fixed location
>>>>>>> in the frame=3D2C while the second is located in the subrecord. Also=
>>=3D2C s=3D
>>>>ometimes the first
>>>>>>> static link value is kept in a register and never stored.
>>>>>>>
>>>>>>> What this all apparently accomplishes is simplifying an "insanely com=
>>pl=3D
>>>>icated" _compile-time_
>>>>>>> scheme that=3D2C I believe came from interaction between nested proce=
>>dure=3D
>>>>s and inlining them.
>>>>>>>
>>>>>>> But it's at the cost of what I would call an insanely complicated _ru=
>>nt=3D
>>>>ime_ scheme.
>>>>>>>
>>>>>>> It undermined m3gdb's handling of static links=3D2C and I don't think=
>> it'=3D
>>>>s possible to fix
>>>>>>> with the current design of emitting debug info very early. The locati=
>>on=3D
>>>>s and target
>>>>>>> offsets of these things aren't know until later=3D2C and m3gdb really=
>> nee=3D
>>>>ds to know them.
>>>>>>>
>>>>>>>
>>>>>>> Jay K wrote:
>>>>>>>> What I meant regarding "static chain" was more like "does gcc alread=
>>y =3D
>>>>have support that we can use".
>>>>>>>> Don't any of the other languages need it already?
>>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>> =3D = 		 	   		  

From mika at async.async.caltech.edu  Fri May 21 09:44:59 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Fri, 21 May 2010 00:44:59 -0700
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl> 
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , , , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , , , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, , , ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, , , ,
	<4BF56D60.2000403@lcwb.coop>, , ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, , ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>, ,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>, ,
	<20100521053756.D74951A2094@async.async.caltech.edu>,
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>,
	<20100521064522.93AAC1A2094@async.async.caltech.edu>
	<COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
Message-ID: <20100521074459.BF5041A2061@async.async.caltech.edu>


In Modula-3 you can pass a nested function in a function call.  It can
be quite useful but it's broken in PM3 so I never use it.

I've been meaning to write an optimistic Scheme compiler that uses tricks
with nested functions passed like that to allocate closures on demand...

(With nested functions, you can essentially set up a mechanism to jump
back up the stack, of course by doubling the recursion depth, and that
you could use to copy the stack into heap memory... something like that)

    Mika

Jay K writes:
>
>Of course. I tried to read it as a teenager and got stuck on the automata s=
>tuff.
>=20
>=20
>Wirth isn't 100% clear to me.
> He describes my two schemes.
> I think he throws out the second as an unimportant optimization.
> He criticizes the first as inefficient=2C granted.
> What I don't get is the static link in addition to the dynamic link.
> Perhaps I have not accounted for recursion.
>=20
>=20
>Oh..I see..he is allowing to take the address of a nested function.
>I didn't account for that.
>I still don't understand all the arrow he draws for the static link=2C but
>I do see that my scheme doesn't suffice.
>Taking the address of a nested function..doesn't seem like a good idea.
>Maybe I'm too C-minded.
>=20
>=20
>My prototypical favorite Scheme example is:
>=20
>=20
>(define (make-adder x)
>   (define (add y) (+ x y))
>   add)
>=20
>=20
>(define add2 (make-adder 2))
>(add2 3) =3D> 5
>=20
>=20
>but Modula-3 doesn't allow for that anyway..
>=20
>Still=2C we make "closures": tuple{-1=2C function pointer=2C frame pointer}
>before calling a pointer=2C we check if it points to -1=2C and if so
>we call function pointer with frame pointer as the link.
>=20
>=20
>And then I guess=2C you might have something like this?
>=20
>=20
>=20
>int F1(int a=2C int b=2C int (*F)())
>{
>  int F2()
>  {
>    return a + b=3B
>  }
>=20
>  if (F !=3D NULL)
>   return F()=3B
>=20
>  return F1(a - 1=2C b - 1=2C &F2)=3B
>=20
>}
>=20
>=20
>F(1=2C 2=2C NULL) =3D> 3
>=20
>=20
>Though that doesn't demonstrate the generality perhaps.
>=20
>=20
>Taking the address of a nested function seems dubious.
>=20
>=20
>My "favorite" bit of Schema:
>=20
>(define (make-adder x)
>   (define (add y) (+ x y))
>   add)
>=20
>=20
>(define add2 (make-adder 2))
>=20
>(add2 3) =3D> 3
>=20
>=20
>But we don't allow that sort of thing -- frames are always stack allocated.
>=20
>=20
>=20
> - Jay
>
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Thu=2C 20 May 2010 23:45:22 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>> The Dragon Book is
>>
>> Aho=2C Sethi=2C Ullman. Compilers: Principles=2C Techniques=2C and Tools.
>> Addison-Wesley=2C 1988. Chapter 7=2C esp. Sec. 7.4.
>>
>> Mika
>>
>> Jay K writes:
>>>
>>>Thanks for the reference!
>>>=3D20
>>>search for "Good Ideas=3D2C Through the Looking Glass"
>>>finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas=
>_o=3D
>>>rigFig.pdf"
>>>(I don't need to provide the link really.)
>>>=3D20
>>> - Jay
>>>
>>>----------------------------------------
>>>> To: jay.krell at cornell.edu
>>>> Date: Thu=3D2C 20 May 2010 22:37:56 -0700
>>>> From: mika at async.async.caltech.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>
>>>>
>>>> As I recall it the "Dragon Book" has a whole section on this topic of
>>>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>>>> an expert=3D2C just remember reading it. Wirth also talks about it in h=
>is
>>>> "Good Ideas=3D2C Through the Looking Glass" (where he says the display
>>>> might be a pessimization).
>>>>
>>>> Mika
>>>>
>>>> Jay K writes:
>>>>>
>>>>>Maybe we can/should transform into one of the forms I show and dispense=
> w=3D
>>>it=3D3D
>>>>>h any gcc support?
>>>>>At the cost of losing some "easy" optimization..of nested functions?
>>>>> "easy" as in=3D3D2C occurs even without -O2=3D3D2C but might occur wit=
>h -O2?
>>>>>=3D3D20
>>>>>=3D3D20
>>>>>I know what you mean -- NT386 passes the static link in ecx.
>>>>>This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>>>=3D3D20
>>>>>=3D3D20
>>>>>Passing it as "just" another parameter might be less efficient=3D3D2C b=
>ut o=3D
>>>k?
>>>>> And really=3D3D2C it'd only be less efficient on one architecture -- 3=
>2bit=3D
>>> x8=3D3D
>>>>>6.
>>>>> And maybe not all x86s -- depending on if some ABIs have a register ba=
>se=3D
>>>d=3D3D
>>>>> calling convention.
>>>>>=3D3D20
>>>>>=3D3D20
>>>>>We don't need any actual ABI-compatibility with anything here=3D3D2C do=
> we?
>>>>>=3D3D20
>>>>>=3D3D20
>>>>> - Jay
>>>>>
>>>>>
>>>>>----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Thu=3D3D2C 20 May 2010 22:22:46 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>
>>>>>> That is the standard formulation=3D3D2C but different architectures h=
>ave =3D
>>>diff=3D3D
>>>>>erent optimised forms (passing static link in a register=3D3D2C etc.). =
>In a=3D
>>>ny c=3D3D
>>>>>ase=3D3D2C gcc has its own weird way of doing things=3D3D2C which we mo=
>stly u=3D
>>>se=3D3D2C =3D3D
>>>>>but from which we need a little extra support (hence the small amount o=
>f =3D
>>>sp=3D3D
>>>>>ecial tailoring).
>>>>>>
>>>>>> On 20 May 2010=3D3D2C at 21:43=3D3D2C Jay K wrote:
>>>>>>
>>>>>>>
>>>>>>> Wierd. To me the model to follow is almost obvious. It should be obv=
>io=3D
>>>us=3D3D
>>>>> to everyone and implemented the way I have in mind. :)
>>>>>>>
>>>>>>>
>>>>>>> The static link is an extra parameter.
>>>>>>> And=3D3D2C as such=3D3D2C also an extra local variable.
>>>>>>> You only need one.
>>>>>>> Each nesting level would follow another chain.
>>>>>>> Or you can pass each nesting level as an extra parameter.
>>>>>>> Or you can optimize and pass locals/parameters separately.
>>>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>>>
>>>>>>>
>>>>>>> Here=3D3D2C I worked it through:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Why doesn't it just look something like this:
>>>>>>>
>>>>>>>
>>>>>>> nested:
>>>>>>>
>>>>>>> void F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D3D a + b=3D3D3B
>>>>>>>
>>>>>>> int f2()
>>>>>>> {
>>>>>>> int d =3D3D3D a + b=3D3D3B
>>>>>>>
>>>>>>> int f3()
>>>>>>> {
>>>>>>> return d + a + c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> return a + c + f3()=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> return f2()=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> not nested:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> f1_frame_t* f1=3D3D3B
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D3D a + b=3D3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> or=3D3D2C alernatively=3D3D2C almost the same=3D3D2C pass each chain=
> as anot=3D
>>>her para=3D3D
>>>>>meter:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3D3B
>>>>>>> void* x86_frame_pointer=3D3D3B
>>>>>>> void* x86_return_address=3D3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2=3D3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D3D2C f1)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D3D a + b=3D3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> This should be easily adapted to any function call convention/sequen=
>ce=3D
>>>.
>>>>>>> e.g. even if parameters are passed in registers.
>>>>>>>
>>>>>>>
>>>>>>> And for that matter=3D3D2C why don't we just transform it to be like=
> thi=3D
>>>s?
>>>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>>>
>>>>>>>
>>>>>>> Am I missing something?
>>>>>>>
>>>>>>>
>>>>>>> This form doesn't work?
>>>>>>>
>>>>>>>
>>>>>>> Isn't reasonably simple?
>>>>>>>
>>>>>>>
>>>>>>> Granted it might not be optimal. But it depends.
>>>>>>> You know=3D3D2C you can copy in the local/parameter values=3D3D2C bu=
>t then=3D
>>> you h=3D3D
>>>>>ave
>>>>>>> to copy them out too. You can do analysis to show they aren't change=
>d=3D
>>>=3D3D2C
>>>>>>> in which case no need to copy them out.
>>>>>>> Similarly you can pass the parameters as separate parameters=3D3D2C =
>by a=3D
>>>ddre=3D3D
>>>>>ss
>>>>>>> if they are ever changed.
>>>>>>>
>>>>>>>
>>>>>>> A portable transform couldn't depend on adjacency of locals and para=
>me=3D
>>>te=3D3D
>>>>>rs.
>>>>>>> It would have to either copy the parameters into the frame_t=3D3D2C =
>or t=3D
>>>heir=3D3D
>>>>> addresses.
>>>>>>>
>>>>>>>
>>>>>>> A portable form couldn't get the frame by taking the address of a "i=
>nd=3D
>>>iv=3D3D
>>>>>idual" local.
>>>>>>>
>>>>>>>
>>>>>>> Here is portable form:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int d=3D3D3B
>>>>>>> f1_frame_t* f1=3D3D3B
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> int c=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3D3B
>>>>>>> f.f1 =3D3D3D f1=3D3D3B
>>>>>>> f.d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3(&f)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3D3B
>>>>>>> f.a =3D3D3D a=3D3D3B
>>>>>>> f.b =3D3D3D b=3D3D3B
>>>>>>> f.c =3D3D3D a + b=3D3D3B
>>>>>>> return f2(&f)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> or:
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int d=3D3D3B
>>>>>>> } f2_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> typedef struct {
>>>>>>> int a=3D3D3B
>>>>>>> int b=3D3D3B
>>>>>>> int c=3D3D3B
>>>>>>> } f1_frame_t=3D3D3B
>>>>>>>
>>>>>>>
>>>>>>> int f3(f2_frame_t* f2=3D3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3D3B
>>>>>>> f.d =3D3D3D f1->a + f1->b=3D3D3B
>>>>>>> return f1->a + f1->c + f3(&f=3D3D2C f1)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int F1(int a=3D3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3D3B
>>>>>>> f.a =3D3D3D a=3D3D3B
>>>>>>> f.b =3D3D3D b=3D3D3B
>>>>>>> f.c =3D3D3D a + b=3D3D3B
>>>>>>> return f2(&f)=3D3D3B
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> Date: Thu=3D3D2C 20 May 2010 12:12:00 -0500
>>>>>>>> From: rodney_bates at lcwb.coop
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>>>
>>>>>>>> gcc even extends C with nested functions=3D3D2C and the support is =
>ther=3D
>>>e fo=3D3D
>>>>>r that. We use it too.
>>>>>>>>
>>>>>>>> Beware: The runtime model is=3D3D2C IMO=3D3D2C bizarre. Definitely =
>counte=3D
>>>rintui=3D3D
>>>>>tive and unlike anything
>>>>>>>> you will ever see elsewhere. There are two static links. One is use=
>d =3D
>>>fo=3D3D
>>>>>r the first step
>>>>>>>> in following a static chain and points to the expected place in the=
> t=3D
>>>ar=3D3D
>>>>>get frame. The other
>>>>>>>> is used of subsequent steps in chain-following=3D3D2C and points to=
> som=3D
>>>ewhe=3D3D
>>>>>re inside the target
>>>>>>>> frame that is dependent on the target procedure. It's the beginning=
> o=3D
>>>f =3D3D
>>>>>a subrecord where
>>>>>>>> all the nonlocally-referenced variables are collected. The second s=
>ta=3D
>>>ti=3D3D
>>>>>c link is also
>>>>>>>> located in there. All the nonlocally-referenced variables and param=
>et=3D
>>>er=3D3D
>>>>>s are duplicated
>>>>>>>> in there too.
>>>>>>>>
>>>>>>>> I'm not sure I remembered these details exactly right. Maybe both l=
>in=3D
>>>ks=3D3D
>>>>> point to the
>>>>>>>> subrecord=3D3D2C but one is located at a traditional procedure-inde=
>pend=3D
>>>ent=3D3D
>>>>>=3D3D2C fixed location
>>>>>>>> in the frame=3D3D2C while the second is located in the subrecord. A=
>lso=3D
>>>=3D3D2C s=3D3D
>>>>>ometimes the first
>>>>>>>> static link value is kept in a register and never stored.
>>>>>>>>
>>>>>>>> What this all apparently accomplishes is simplifying an "insanely c=
>om=3D
>>>pl=3D3D
>>>>>icated" _compile-time_
>>>>>>>> scheme that=3D3D2C I believe came from interaction between nested p=
>roce=3D
>>>dure=3D3D
>>>>>s and inlining them.
>>>>>>>>
>>>>>>>> But it's at the cost of what I would call an insanely complicated _=
>ru=3D
>>>nt=3D3D
>>>>>ime_ scheme.
>>>>>>>>
>>>>>>>> It undermined m3gdb's handling of static links=3D3D2C and I don't t=
>hink=3D
>>> it'=3D3D
>>>>>s possible to fix
>>>>>>>> with the current design of emitting debug info very early. The loca=
>ti=3D
>>>on=3D3D
>>>>>s and target
>>>>>>>> offsets of these things aren't know until later=3D3D2C and m3gdb re=
>ally=3D
>>> nee=3D3D
>>>>>ds to know them.
>>>>>>>>
>>>>>>>>
>>>>>>>> Jay K wrote:
>>>>>>>>> What I meant regarding "static chain" was more like "does gcc alre=
>ad=3D
>>>y =3D3D
>>>>>have support that we can use".
>>>>>>>>> Don't any of the other languages need it already?
>>>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>> =3D3D =3D 		 	   		  =


From hendrik at topoi.pooq.com  Fri May 21 08:59:09 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 21 May 2010 02:59:09 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
References: <20100521064522.93AAC1A2094@async.async.caltech.edu>
	<COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
Message-ID: <20100521065909.GA27981@topoi.pooq.com>

On Fri, May 21, 2010 at 07:41:46AM +0000, Jay K wrote:
> 
> Oh..I see..he is allowing to take the address of a nested function.
> I didn't account for that.
> I still don't understand all the arrow he draws for the static link, but
> I do see that my scheme doesn't suffice.
> Taking the address of a nested function..doesn't seem like a good idea.

Works fine as long as you only use it within other nested stuff.  Very 
useful.  It's the way call-by-name in Algol 60 was implemented.  And if 
you were to put the stack on the heap and garbage-collect it (which 
can cost a lot (Scheme does this, not recommended for Modula 3)), you 
don't need the nesting restriction.

> Maybe I'm too C-minded.

-- hendrik



From jay.krell at cornell.edu  Fri May 21 14:54:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 21 May 2010 12:54:35 +0000
Subject: [M3devel] RC5?
Message-ID: <COL101-W38D3ADE3E3D08C7CDE0549E6E40@phx.gbl>


RC5 packages have been here a month: http://www.opencm3.net/releng/download.html

Any users?

?- Jay





 		 	   		  

From hosking at cs.purdue.edu  Fri May 21 19:08:02 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 21 May 2010 13:08:02 -0400
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , , , , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, , , , ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, , , , ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>, , , ,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>, , , ,
	<4BF56D60.2000403@lcwb.coop>, , ,
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>, , ,
	<AC38AAB4-C92C-489C-AB92-E5A22FB87FDE@cs.purdue.edu>, ,
	<COL101-W18C33922CD4BBC1463CB6E6E40@phx.gbl>, ,
	<20100521053756.D74951A2094@async.async.caltech.edu>,
	<COL101-W62B5841AA922ECC333168E6E40@phx.gbl>,
	<20100521064522.93AAC1A2094@async.async.caltech.edu>
	<COL101-W60A0AA1B22F2DDAA8240F5E6E40@phx.gbl>
Message-ID: <A5424DAE-BAB3-456A-B059-82FAF82EE986@cs.purdue.edu>

We don't want to bypass the gcc support.
It works well with register allocation, etc.


On 21 May 2010, at 03:41, Jay K wrote:

> 
> Of course. I tried to read it as a teenager and got stuck on the automata stuff.
> 
> 
> Wirth isn't 100% clear to me.
> He describes my two schemes.
> I think he throws out the second as an unimportant optimization.
> He criticizes the first as inefficient, granted.
> What I don't get is the static link in addition to the dynamic link.
> Perhaps I have not accounted for recursion.
> 
> 
> Oh..I see..he is allowing to take the address of a nested function.
> I didn't account for that.
> I still don't understand all the arrow he draws for the static link, but
> I do see that my scheme doesn't suffice.
> Taking the address of a nested function..doesn't seem like a good idea.
> Maybe I'm too C-minded.
> 
> 
> My prototypical favorite Scheme example is:
> 
> 
> (define (make-adder x)
>   (define (add y) (+ x y))
>   add)
> 
> 
> (define add2 (make-adder 2))
> (add2 3) => 5
> 
> 
> but Modula-3 doesn't allow for that anyway..
> 
> Still, we make "closures": tuple{-1, function pointer, frame pointer}
> before calling a pointer, we check if it points to -1, and if so
> we call function pointer with frame pointer as the link.
> 
> 
> And then I guess, you might have something like this?
> 
> 
> 
> int F1(int a, int b, int (*F)())
> {
>  int F2()
>  {
>    return a + b;
>  }
> 
>  if (F != NULL)
>   return F();
> 
>  return F1(a - 1, b - 1, &F2);
> 
> }
> 
> 
> F(1, 2, NULL) => 3
> 
> 
> Though that doesn't demonstrate the generality perhaps.
> 
> 
> Taking the address of a nested function seems dubious.
> 
> 
> My "favorite" bit of Schema:
> 
> (define (make-adder x)
>   (define (add y) (+ x y))
>   add)
> 
> 
> (define add2 (make-adder 2))
> 
> (add2 3) => 3
> 
> 
> But we don't allow that sort of thing -- frames are always stack allocated.
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Thu, 20 May 2010 23:45:22 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>> 
>> The Dragon Book is
>> 
>> Aho, Sethi, Ullman. Compilers: Principles, Techniques, and Tools.
>> Addison-Wesley, 1988. Chapter 7, esp. Sec. 7.4.
>> 
>> Mika
>> 
>> Jay K writes:
>>> 
>>> Thanks for the reference!
>>> =20
>>> search for "Good Ideas=2C Through the Looking Glass"
>>> finds it right away: "http://www.cs.inf.ethz.ch/~wirth/Articles/GoodIdeas_o=
>>> rigFig.pdf"
>>> (I don't need to provide the link really.)
>>> =20
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> To: jay.krell at cornell.edu
>>>> Date: Thu=2C 20 May 2010 22:37:56 -0700
>>>> From: mika at async.async.caltech.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>> 
>>>> 
>>>> As I recall it the "Dragon Book" has a whole section on this topic of
>>>> nested functions in Pascal. Including Dijkstra's "display". I'm not
>>>> an expert=2C just remember reading it. Wirth also talks about it in his
>>>> "Good Ideas=2C Through the Looking Glass" (where he says the display
>>>> might be a pessimization).
>>>> 
>>>> Mika
>>>> 
>>>> Jay K writes:
>>>>> 
>>>>> Maybe we can/should transform into one of the forms I show and dispense w=
>>> it=3D
>>>>> h any gcc support?
>>>>> At the cost of losing some "easy" optimization..of nested functions?
>>>>> "easy" as in=3D2C occurs even without -O2=3D2C but might occur with -O2?
>>>>> =3D20
>>>>> =3D20
>>>>> I know what you mean -- NT386 passes the static link in ecx.
>>>>> This is "ok" because in C++ the "this" pointer is passed in ecx.
>>>>> =3D20
>>>>> =3D20
>>>>> Passing it as "just" another parameter might be less efficient=3D2C but o=
>>> k?
>>>>> And really=3D2C it'd only be less efficient on one architecture -- 32bit=
>>> x8=3D
>>>>> 6.
>>>>> And maybe not all x86s -- depending on if some ABIs have a register base=
>>> d=3D
>>>>> calling convention.
>>>>> =3D20
>>>>> =3D20
>>>>> We don't need any actual ABI-compatibility with anything here=3D2C do we?
>>>>> =3D20
>>>>> =3D20
>>>>> - Jay
>>>>> 
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Thu=3D2C 20 May 2010 22:22:46 -0400
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>> 
>>>>>> That is the standard formulation=3D2C but different architectures have =
>>> diff=3D
>>>>> erent optimised forms (passing static link in a register=3D2C etc.). In a=
>>> ny c=3D
>>>>> ase=3D2C gcc has its own weird way of doing things=3D2C which we mostly u=
>>> se=3D2C =3D
>>>>> but from which we need a little extra support (hence the small amount of =
>>> sp=3D
>>>>> ecial tailoring).
>>>>>> 
>>>>>> On 20 May 2010=3D2C at 21:43=3D2C Jay K wrote:
>>>>>> 
>>>>>>> 
>>>>>>> Wierd. To me the model to follow is almost obvious. It should be obvio=
>>> us=3D
>>>>> to everyone and implemented the way I have in mind. :)
>>>>>>> 
>>>>>>> 
>>>>>>> The static link is an extra parameter.
>>>>>>> And=3D2C as such=3D2C also an extra local variable.
>>>>>>> You only need one.
>>>>>>> Each nesting level would follow another chain.
>>>>>>> Or you can pass each nesting level as an extra parameter.
>>>>>>> Or you can optimize and pass locals/parameters separately.
>>>>>>> But there is an obvious straightforward non-optimized form. ?
>>>>>>> 
>>>>>>> 
>>>>>>> Here=3D2C I worked it through:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Why doesn't it just look something like this:
>>>>>>> 
>>>>>>> 
>>>>>>> nested:
>>>>>>> 
>>>>>>> void F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D a + b=3D3B
>>>>>>> 
>>>>>>> int f2()
>>>>>>> {
>>>>>>> int d =3D3D a + b=3D3B
>>>>>>> 
>>>>>>> int f3()
>>>>>>> {
>>>>>>> return d + a + c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> return a + c + f3()=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> return f2()=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> not nested:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> f1_frame_t* f1=3D3B
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D a + b=3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> or=3D2C alernatively=3D2C almost the same=3D2C pass each chain as anot=
>>> her para=3D
>>>>> meter:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int d=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> /* locals */
>>>>>>> int c=3D3B
>>>>>>> void* x86_frame_pointer=3D3B
>>>>>>> void* x86_return_address=3D3B
>>>>>>> /* parameters */
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> int d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3((f2_frame_t*)&d=3D2C f1)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> int c =3D3D a + b=3D3B
>>>>>>> return f2((f1_frame_t*)&c)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> This should be easily adapted to any function call convention/sequence=
>>> .
>>>>>>> e.g. even if parameters are passed in registers.
>>>>>>> 
>>>>>>> 
>>>>>>> And for that matter=3D2C why don't we just transform it to be like thi=
>>> s?
>>>>>>> With the goal of reducing/eliminating gcc patches?
>>>>>>> 
>>>>>>> 
>>>>>>> Am I missing something?
>>>>>>> 
>>>>>>> 
>>>>>>> This form doesn't work?
>>>>>>> 
>>>>>>> 
>>>>>>> Isn't reasonably simple?
>>>>>>> 
>>>>>>> 
>>>>>>> Granted it might not be optimal. But it depends.
>>>>>>> You know=3D2C you can copy in the local/parameter values=3D2C but then=
>>> you h=3D
>>>>> ave
>>>>>>> to copy them out too. You can do analysis to show they aren't changed=
>>> =3D2C
>>>>>>> in which case no need to copy them out.
>>>>>>> Similarly you can pass the parameters as separate parameters=3D2C by a=
>>> ddre=3D
>>>>> ss
>>>>>>> if they are ever changed.
>>>>>>> 
>>>>>>> 
>>>>>>> A portable transform couldn't depend on adjacency of locals and parame=
>>> te=3D
>>>>> rs.
>>>>>>> It would have to either copy the parameters into the frame_t=3D2C or t=
>>> heir=3D
>>>>> addresses.
>>>>>>> 
>>>>>>> 
>>>>>>> A portable form couldn't get the frame by taking the address of a "ind=
>>> iv=3D
>>>>> idual" local.
>>>>>>> 
>>>>>>> 
>>>>>>> Here is portable form:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int d=3D3B
>>>>>>> f1_frame_t* f1=3D3B
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> int c=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2)
>>>>>>> {
>>>>>>> return f2->d + f2->f1->a + f2->f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3B
>>>>>>> f.f1 =3D3D f1=3D3B
>>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3(&f)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3B
>>>>>>> f.a =3D3D a=3D3B
>>>>>>> f.b =3D3D b=3D3B
>>>>>>> f.c =3D3D a + b=3D3B
>>>>>>> return f2(&f)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> or:
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int d=3D3B
>>>>>>> } f2_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> typedef struct {
>>>>>>> int a=3D3B
>>>>>>> int b=3D3B
>>>>>>> int c=3D3B
>>>>>>> } f1_frame_t=3D3B
>>>>>>> 
>>>>>>> 
>>>>>>> int f3(f2_frame_t* f2=3D2C f1_frame_t* f1)
>>>>>>> {
>>>>>>> return f2->d + f1->a + f1->c=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int f2(f1_frame_t* f1)
>>>>>>> {
>>>>>>> f2_frame_t f=3D3B
>>>>>>> f.d =3D3D f1->a + f1->b=3D3B
>>>>>>> return f1->a + f1->c + f3(&f=3D2C f1)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> int F1(int a=3D2C int b)
>>>>>>> {
>>>>>>> f1_frame_t f=3D3B
>>>>>>> f.a =3D3D a=3D3B
>>>>>>> f.b =3D3D b=3D3B
>>>>>>> f.c =3D3D a + b=3D3B
>>>>>>> return f2(&f)=3D3B
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> - Jay
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> Date: Thu=3D2C 20 May 2010 12:12:00 -0500
>>>>>>>> From: rodney_bates at lcwb.coop
>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] gcc 4.5.0?
>>>>>>>> 
>>>>>>>> gcc even extends C with nested functions=3D2C and the support is ther=
>>> e fo=3D
>>>>> r that. We use it too.
>>>>>>>> 
>>>>>>>> Beware: The runtime model is=3D2C IMO=3D2C bizarre. Definitely counte=
>>> rintui=3D
>>>>> tive and unlike anything
>>>>>>>> you will ever see elsewhere. There are two static links. One is used =
>>> fo=3D
>>>>> r the first step
>>>>>>>> in following a static chain and points to the expected place in the t=
>>> ar=3D
>>>>> get frame. The other
>>>>>>>> is used of subsequent steps in chain-following=3D2C and points to som=
>>> ewhe=3D
>>>>> re inside the target
>>>>>>>> frame that is dependent on the target procedure. It's the beginning o=
>>> f =3D
>>>>> a subrecord where
>>>>>>>> all the nonlocally-referenced variables are collected. The second sta=
>>> ti=3D
>>>>> c link is also
>>>>>>>> located in there. All the nonlocally-referenced variables and paramet=
>>> er=3D
>>>>> s are duplicated
>>>>>>>> in there too.
>>>>>>>> 
>>>>>>>> I'm not sure I remembered these details exactly right. Maybe both lin=
>>> ks=3D
>>>>> point to the
>>>>>>>> subrecord=3D2C but one is located at a traditional procedure-independ=
>>> ent=3D
>>>>> =3D2C fixed location
>>>>>>>> in the frame=3D2C while the second is located in the subrecord. Also=
>>> =3D2C s=3D
>>>>> ometimes the first
>>>>>>>> static link value is kept in a register and never stored.
>>>>>>>> 
>>>>>>>> What this all apparently accomplishes is simplifying an "insanely com=
>>> pl=3D
>>>>> icated" _compile-time_
>>>>>>>> scheme that=3D2C I believe came from interaction between nested proce=
>>> dure=3D
>>>>> s and inlining them.
>>>>>>>> 
>>>>>>>> But it's at the cost of what I would call an insanely complicated _ru=
>>> nt=3D
>>>>> ime_ scheme.
>>>>>>>> 
>>>>>>>> It undermined m3gdb's handling of static links=3D2C and I don't think=
>>> it'=3D
>>>>> s possible to fix
>>>>>>>> with the current design of emitting debug info very early. The locati=
>>> on=3D
>>>>> s and target
>>>>>>>> offsets of these things aren't know until later=3D2C and m3gdb really=
>>> nee=3D
>>>>> ds to know them.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Jay K wrote:
>>>>>>>>> What I meant regarding "static chain" was more like "does gcc alread=
>>> y =3D
>>>>> have support that we can use".
>>>>>>>>> Don't any of the other languages need it already?
>>>>>>>>> Ada? Pascal? Maybe the nested C function support?
>>>>>>>>> 
>>>>>>>>> - Jay
>>>>>>>>> 
>>>>>> =3D = 		 	   		  



From rodney_bates at lcwb.coop  Fri May 21 21:45:32 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Fri, 21 May 2010 14:45:32 -0500
Subject: [M3devel] gcc 4.5.0?
In-Reply-To: <COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
References: <COL101-W34B09B659C8AE42741F2F1E6E30@phx.gbl>, , ,
	<76613531-CF80-4ADB-BEB9-F51D631CDD4D@cs.purdue.edu>, ,
	<COL101-W1840C8D8AB42A08C878E59E6E30@phx.gbl>, ,
	<2E13C1A4-0410-477E-80CC-8FB62D1EA524@cs.purdue.edu>,
	<COL101-W5158D068A4C3071A272BDFE6E30@phx.gbl>,
	<4BF56D60.2000403@lcwb.coop>
	<COL101-W829B20749B4BFF0A4A5C8E6E40@phx.gbl>
Message-ID: <4BF6E2DC.3090601@lcwb.coop>

I have no quarrels with you there, Jay.  I'm not advocating it, just
reporting what I know about how gcc does it.

Jay K wrote:
> Wierd. To me the model to follow is almost obvious. It should be obvious to everyone and implemented the way I have in mind. :)
>  
>  
> The static link is an extra parameter.
> And, as such, also an extra local variable.
> You only need one.
> Each nesting level would follow another chain.
> Or you can pass each nesting level as an extra parameter.
> Or you can optimize and pass locals/parameters separately.
> But there is an obvious straightforward non-optimized form. ?
>  
>  
> Here, I worked it through:
>  
>  
>  
> Why doesn't it just look something like this:
>  
>  
> nested:
>  
> void F1(int a, int b)
> {
>   int c = a + b;
>  
>   int f2()
>   {
>     int d = a + b;
>  
>     int f3()
>     {
>        return d + a + c;
>     }
>  
>     return a + c + f3();
>   }
>  
>   return f2();
> }
>  
> not nested:
>  
> 
> typedef struct {
>   /* locals */
>   int d;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
>   f1_frame_t* f1;
> } f2_frame_t;
>  
> 
> typedef struct {
>   /* locals */
>   int c;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
>   int a;
>   int b;
> } f1_frame_t;
>  
>  
> int f3(f2_frame_t* f2)
> {
>     return f2->d + f2->f1->a + f2->f1->c;
> }
>  
> 
> int f2(f1_frame_t* f1)
> {
>   int d = f1->a + f1->b;
>   return f1->a + f1->c + f3((f2_frame_t*)&d);
> }
>  
> 
> int F1(int a, int b)
> {
>   int c = a + b;
>   return f2((f1_frame_t*)&c);
> }
> 
>  
> or, alernatively, almost the same, pass each chain as another parameter:
>  
> 
> typedef struct {
>   /* locals */
>   int d;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
> } f2_frame_t;
>  
> 
> typedef struct {
>   /* locals */
>   int c;
>   void* x86_frame_pointer;
>   void* x86_return_address;
>   /* parameters */
>   int a;
>   int b;
> } f1_frame_t;
>  
>  
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>     return f2->d + f1->a + f1->c;
> }
>  
>  
> 
> int f2(f1_frame_t* f1)
> {
>   int d = f1->a + f1->b;
>   return f1->a + f1->c + f3((f2_frame_t*)&d, f1);
> }
>  
> 
> int F1(int a, int b)
> {
>   int c = a + b;
>   return f2((f1_frame_t*)&c);
> }
>  
>  
> This should be easily adapted to any function call convention/sequence.
> e.g. even if parameters are passed in registers.
>  
>  
> And for that matter, why don't we just transform it to be like this?
>   With the goal of reducing/eliminating gcc patches?
>  
>  
> Am I missing something?
>  
> 
> This form doesn't work?
>  
> 
> Isn't reasonably simple?
>  
> 
> Granted it might not be optimal. But it depends.
>   You know, you can copy in the local/parameter values, but then you have
>    to copy them out too. You can do analysis to show they aren't changed,
>    in which case no need to copy them out.
>   Similarly you can pass the parameters as separate parameters, by address
>    if they are ever changed.
> 
>  
> A portable transform couldn't depend on adjacency of locals and parameters.
> It would have to either copy the parameters into the frame_t, or their addresses.
>  
>  
> A portable form couldn't get the frame by taking the address of a "individual" local.
>  
>  
> Here is portable form:
>  
>  
> typedef struct {
>   int d;
>   f1_frame_t* f1;
> } f2_frame_t;
>  
> typedef struct {
>   int a;
>   int b;
>   int c;
> } f1_frame_t;
>  
> 
> int f3(f2_frame_t* f2)
> {
>     return f2->d + f2->f1->a + f2->f1->c;
> }
>  
> int f2(f1_frame_t* f1)
> {
>   f2_frame_t f;
>   f.f1 = f1;
>   f.d = f1->a + f1->b;
>   return f1->a + f1->c + f3(&f);
> }
>  
>  
> int F1(int a, int b)
> {
>   f1_frame_t f;
>   f.a = a;
>   f.b = b;
>   f.c = a + b;
>   return f2(&f);
> }
>  
>  
> or:
>  
>  
> typedef struct {
>   int d;
> } f2_frame_t;
>  
>  
> typedef struct {
>   int a;
>   int b;
>   int c;
> } f1_frame_t;
>  
>  
> int f3(f2_frame_t* f2, f1_frame_t* f1)
> {
>     return f2->d + f1->a + f1->c;
> }
>  
>  
> int f2(f1_frame_t* f1)
> {
>   f2_frame_t f;
>   f.d = f1->a + f1->b;
>   return f1->a + f1->c + f3(&f, f1);
> }
> 
>  
> int F1(int a, int b)
> {
>   f1_frame_t f;
>   f.a = a;
>   f.b = b;
>   f.c = a + b;
>   return f2(&f);
> }
> 
>  
>  
>  
>  - Jay
> 
> 
> 
> ----------------------------------------
>> Date: Thu, 20 May 2010 12:12:00 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] gcc 4.5.0?
>>
>> gcc even extends C with nested functions, and the support is there for that. We use it too.
>>
>> Beware: The runtime model is, IMO, bizarre. Definitely counterintuitive and unlike anything
>> you will ever see elsewhere. There are two static links. One is used for the first step
>> in following a static chain and points to the expected place in the target frame. The other
>> is used of subsequent steps in chain-following, and points to somewhere inside the target
>> frame that is dependent on the target procedure. It's the beginning of a subrecord where
>> all the nonlocally-referenced variables are collected. The second static link is also
>> located in there. All the nonlocally-referenced variables and parameters are duplicated
>> in there too.
>>
>> I'm not sure I remembered these details exactly right. Maybe both links point to the
>> subrecord, but one is located at a traditional procedure-independent, fixed location
>> in the frame, while the second is located in the subrecord. Also, sometimes the first
>> static link value is kept in a register and never stored.
>>
>> What this all apparently accomplishes is simplifying an "insanely complicated" _compile-time_
>> scheme that, I believe came from interaction between nested procedures and inlining them.
>>
>> But it's at the cost of what I would call an insanely complicated _runtime_ scheme.
>>
>> It undermined m3gdb's handling of static links, and I don't think it's possible to fix
>> with the current design of emitting debug info very early. The locations and target
>> offsets of these things aren't know until later, and m3gdb really needs to know them.
>>
>>
>> Jay K wrote:
>>> What I meant regarding "static chain" was more like "does gcc already have support that we can use".
>>> Don't any of the other languages need it already?
>>> Ada? Pascal? Maybe the nested C function support?
>>>
>>> - Jay
>>> 		 	   		  


From mika at async.async.caltech.edu  Sat May 22 23:53:17 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 22 May 2010 14:53:17 -0700
Subject: [M3devel] OS for CM3
Message-ID: <20100522215317.E428D1A2096@async.async.caltech.edu>

Hi Modula-3ers,

Can anyone give me some advice on what OS to install on a new PC compute
server with 16 to 24 cores and 16 to 32 GB of RAM?  The code I'm going
to be running is all written in Modula-3 with some C and Fortran thrown
in and I want to use CM3.  The odd extra thing in Java and some analysis
in R.  Currently I'm stuck with PM3 on FreeBSD/i386.

I've always liked the ease of administration (i.e., I'm an old dog and I
don't have to learn anything new) of FreeBSD, but the threading support
seems much better with Linux?  I do really want to run multi-threaded
programs across several CPUs.

I am considering Debian/amd64.  Any other recommendations, experiences?

    Mika


From dragisha at m3w.org  Sun May 23 00:32:25 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 23 May 2010 00:32:25 +0200
Subject: [M3devel] OS for CM3
In-Reply-To: <20100522215317.E428D1A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
Message-ID: <1274567545.29716.4.camel@localhost>

There is no simple nor unique answer to this. I prefer Fedora, and I've
been using RedHat since 1996... Some people prefer RHEL, or CentOS if
they like it freer. Jumped of SLS then Slackware I've been using from
1993-1995, and never looked back.

Easy to administer and maintain, most of modern distros have GUI for
every admin task.

On Sat, 2010-05-22 at 14:53 -0700, Mika Nystrom wrote:
> Hi Modula-3ers,
> 
> Can anyone give me some advice on what OS to install on a new PC compute
> server with 16 to 24 cores and 16 to 32 GB of RAM?  The code I'm going
> to be running is all written in Modula-3 with some C and Fortran thrown
> in and I want to use CM3.  The odd extra thing in Java and some analysis
> in R.  Currently I'm stuck with PM3 on FreeBSD/i386.
> 
> I've always liked the ease of administration (i.e., I'm an old dog and I
> don't have to learn anything new) of FreeBSD, but the threading support
> seems much better with Linux?  I do really want to run multi-threaded
> programs across several CPUs.
> 
> I am considering Debian/amd64.  Any other recommendations, experiences?
> 
>     Mika

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



From jay.krell at cornell.edu  Sun May 23 01:35:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 22 May 2010 23:35:52 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <1274567545.29716.4.camel@localhost>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
Message-ID: <COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl>


Modula-3 will run on almost anything. Install something we don't work on yet and give me ssh access. :)
Like get a Loongson laptop -- comes with Linux/MIPS but can also run OpenBSD and maybe others.
Or, install something we don't have yet in Hudson yet, e.g. NetBSD/amd64, and have Olaf add jobs for it.

Seriously, for Hudson purposes, NetBSD/amd64 is probably the best, followed by NetBSD/x86.
I'll set these up eventually.


Regarding Linux, I've been using Debian, because it has about the best support for multiple architectures.
? And then the same "experience" across all of them -- same installer and package management.


Gentoo would be the next or previous choice -- not clear what the ppc64 support is in Debian.
It helps that I first used wimpy Ubuntu before moving up to the supposedly manly Debian.
Gentoo I've had trouble getting to install+boot.


OpenBSD has about the best install experience imho and a certain hard to capture purity about it.
? Examples:
???? NetBSD and FreeBSD support powerpc.
???? FreeBSD's partitioner doesn't run on powerpc though.
???? NetBSD I couldn't get to install.
???? OpenBSD was easy.
?? 
???? Attempting to install Linux or NetBSD on an SGI machine apparently killed the machine.
???? I couldn't get either to install or boot. One of them might not have local console working.
???? But again OpenBSD was easy and worked.


??? My OpenBSD/sgimips CD was actually bad. But it worked enough to boot, and the
??? the install was then easy to fallback to over the network.


But they don't have kernel threads, so, while we work, we probably scale the worst here.
? Besides, user threads are an /option/ on all Posix systems, only /required/ on OpenBSD.


I think all the user interfaces are terrible though.
I am most productive by far on NT, using find-in-files countless times daily in Visual C++ 5.0.
?It is so much better than command line grep, and it beats every other IDE/editor I have tried,
?and I have tried many. Komodo Edit is so-so. MonoDevelop was promising, but it refused
?to open *.m3 files as plain text. TextWrangler on Mac is so-so, what I use for lack
?of anything good. Eclipse is confusing to install and I don't think worked well, but I forget.


Mac is distant second in productivity.
? At least I don't have to constantly flip the newlines and it has a fast fork.


Everything else I can't even edit files on. I can't copy/paste, navigate quickly (e.g. esp. using
page up/down/home/end/mouse!). NT also has a fast console with half decent most support.


My most productive pattern is editing on NT and copying files around otherwise.


As well, consider that the NT Modula-3 backend is unique and pretty darn good.
? It is fast, in-proc, and always optimizes a certain amount.
? In its only mode, it generates significantly better code than unoptimizing gcc.


?Compiling N files on NT takes one process to compile, codegen, write objs files,
and then another one or two to link.


Compiling N files on the other systems takes one process to compile, N runs
of m3cg to generate N asssembly files, N runs to run the assembler.


If you really need an *occasional* Posixy experience on NT, there is Cygwin and SFU/SUA.
Cygwin has a very slow fork and it is very noticable.
SFU/SUA has a "normally" fast fork, and it is very noticable.


FreeBSD, Solaris, NetBSD, Linux -- should all be about the same.
?(ok, Solaris/x86 support is only in head, not release).


Then there are the non-x86 ones, like HP-UX, OSF/1, Irix, AIX, VMS... :)


Also, for Hudson purposes, we need Java.
That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
Linux now has good enough Java on all architectures.
? There was a project to eliminate all the assembly code. And we have no problem
??? e.g. now on Linux/sparc and Linux/powerpc.

All the commercial systems probably suffice also.

?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: mika at async.async.caltech.edu
> Date: Sun, 23 May 2010 00:32:25 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] OS for CM3
>
> There is no simple nor unique answer to this. I prefer Fedora, and I've
> been using RedHat since 1996... Some people prefer RHEL, or CentOS if
> they like it freer. Jumped of SLS then Slackware I've been using from
> 1993-1995, and never looked back.
>
> Easy to administer and maintain, most of modern distros have GUI for
> every admin task.
>
> On Sat, 2010-05-22 at 14:53 -0700, Mika Nystrom wrote:
>> Hi Modula-3ers,
>>
>> Can anyone give me some advice on what OS to install on a new PC compute
>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
>> to be running is all written in Modula-3 with some C and Fortran thrown
>> in and I want to use CM3. The odd extra thing in Java and some analysis
>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
>>
>> I've always liked the ease of administration (i.e., I'm an old dog and I
>> don't have to learn anything new) of FreeBSD, but the threading support
>> seems much better with Linux? I do really want to run multi-threaded
>> programs across several CPUs.
>>
>> I am considering Debian/amd64. Any other recommendations, experiences?
>>
>> Mika
>
> --
> Dragi?a Duri? 
>
 		 	   		  

From jay.krell at cornell.edu  Sun May 23 01:40:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 22 May 2010 23:40:46 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <1274567545.29716.4.camel@localhost>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
Message-ID: <COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>


ps: Slackware was fine back when I used it. RedHat is ok, but it at least used to take forever to do any package management compared to Ubuntu/Debian.
Suse has/had RedHat's problem, also being rpm basedi but also seemed to lead in gui/managability.


Anyway, other than Mac and NT, all my other systems are now ssh command line and impossible to do much with. :)


ps: I also like *BSD due to the reduced number of choices, and the "integrated build", where you can build a bit
more in one nice go, not just the kernel. Linux is so darn chaotic.
But I rarely take any advantage of this.
I would really like, whatever I run, to build the entire thing from source, and do it fairly easily.
?Have the whole thing be debuggable.
?Cross building support would be nice too, though lately people seem to give up and use qemu.
? Too much building stuff wants to run as it builds, like using autoconf.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: dragisha at m3w.org; mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] OS for CM3
> Date: Sat, 22 May 2010 23:35:52 +0000
>
>
> Modula-3 will run on almost anything. Install something we don't work on yet and give me ssh access. :)
> Like get a Loongson laptop -- comes with Linux/MIPS but can also run OpenBSD and maybe others.
> Or, install something we don't have yet in Hudson yet, e.g. NetBSD/amd64, and have Olaf add jobs for it.
>
> Seriously, for Hudson purposes, NetBSD/amd64 is probably the best, followed by NetBSD/x86.
> I'll set these up eventually.
>
>
> Regarding Linux, I've been using Debian, because it has about the best support for multiple architectures.
>   And then the same "experience" across all of them -- same installer and package management.
>
>
> Gentoo would be the next or previous choice -- not clear what the ppc64 support is in Debian.
> It helps that I first used wimpy Ubuntu before moving up to the supposedly manly Debian.
> Gentoo I've had trouble getting to install+boot.
>
>
> OpenBSD has about the best install experience imho and a certain hard to capture purity about it.
>   Examples:
>      NetBSD and FreeBSD support powerpc.
>      FreeBSD's partitioner doesn't run on powerpc though.
>      NetBSD I couldn't get to install.
>      OpenBSD was easy.
>
>      Attempting to install Linux or NetBSD on an SGI machine apparently killed the machine.
>      I couldn't get either to install or boot. One of them might not have local console working.
>      But again OpenBSD was easy and worked.
>
>
>     My OpenBSD/sgimips CD was actually bad. But it worked enough to boot, and the
>     the install was then easy to fallback to over the network.
>
>
> But they don't have kernel threads, so, while we work, we probably scale the worst here.
>   Besides, user threads are an /option/ on all Posix systems, only /required/ on OpenBSD.
>
>
> I think all the user interfaces are terrible though.
> I am most productive by far on NT, using find-in-files countless times daily in Visual C++ 5.0.
>  It is so much better than command line grep, and it beats every other IDE/editor I have tried,
>  and I have tried many. Komodo Edit is so-so. MonoDevelop was promising, but it refused
>  to open *.m3 files as plain text. TextWrangler on Mac is so-so, what I use for lack
>  of anything good. Eclipse is confusing to install and I don't think worked well, but I forget.
>
>
> Mac is distant second in productivity.
>   At least I don't have to constantly flip the newlines and it has a fast fork.
>
>
> Everything else I can't even edit files on. I can't copy/paste, navigate quickly (e.g. esp. using
> page up/down/home/end/mouse!). NT also has a fast console with half decent most support.
>
>
> My most productive pattern is editing on NT and copying files around otherwise.
>
>
> As well, consider that the NT Modula-3 backend is unique and pretty darn good.
>   It is fast, in-proc, and always optimizes a certain amount.
>   In its only mode, it generates significantly better code than unoptimizing gcc.
>
>
>  Compiling N files on NT takes one process to compile, codegen, write objs files,
> and then another one or two to link.
>
>
> Compiling N files on the other systems takes one process to compile, N runs
> of m3cg to generate N asssembly files, N runs to run the assembler.
>
>
> If you really need an *occasional* Posixy experience on NT, there is Cygwin and SFU/SUA.
> Cygwin has a very slow fork and it is very noticable.
> SFU/SUA has a "normally" fast fork, and it is very noticable.
>
>
> FreeBSD, Solaris, NetBSD, Linux -- should all be about the same.
>  (ok, Solaris/x86 support is only in head, not release).
>
>
> Then there are the non-x86 ones, like HP-UX, OSF/1, Irix, AIX, VMS... :)
>
>
> Also, for Hudson purposes, we need Java.
> That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
> Linux now has good enough Java on all architectures.
>   There was a project to eliminate all the assembly code. And we have no problem
>     e.g. now on Linux/sparc and Linux/powerpc.
>
> All the commercial systems probably suffice also.
>
>  - Jay
>
> ----------------------------------------
>> From: dragisha at m3w.org
>> To: mika at async.async.caltech.edu
>> Date: Sun, 23 May 2010 00:32:25 +0200
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] OS for CM3
>>
>> There is no simple nor unique answer to this. I prefer Fedora, and I've
>> been using RedHat since 1996... Some people prefer RHEL, or CentOS if
>> they like it freer. Jumped of SLS then Slackware I've been using from
>> 1993-1995, and never looked back.
>>
>> Easy to administer and maintain, most of modern distros have GUI for
>> every admin task.
>>
>> On Sat, 2010-05-22 at 14:53 -0700, Mika Nystrom wrote:
>>> Hi Modula-3ers,
>>>
>>> Can anyone give me some advice on what OS to install on a new PC compute
>>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
>>> to be running is all written in Modula-3 with some C and Fortran thrown
>>> in and I want to use CM3. The odd extra thing in Java and some analysis
>>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
>>>
>>> I've always liked the ease of administration (i.e., I'm an old dog and I
>>> don't have to learn anything new) of FreeBSD, but the threading support
>>> seems much better with Linux? I do really want to run multi-threaded
>>> programs across several CPUs.
>>>
>>> I am considering Debian/amd64. Any other recommendations, experiences?
>>>
>>> Mika
>>
>> --
>> Dragi?a Duri?
>>
>
 		 	   		  

From mika at async.async.caltech.edu  Sun May 23 02:08:49 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 22 May 2010 17:08:49 -0700
Subject: [M3devel] OS for CM3
In-Reply-To: <COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl> 
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
	<COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>
Message-ID: <20100523000849.BA8E61A2096@async.async.caltech.edu>

Well I know all about the various OS tradeoffs, I was asking more
about Modula-3 itself.

I want to use kernel threads, so I can share large data structures 
across CPUs.  This is for production work, not a development platform.
My main development platform will probably stay FreeBSD/i386 for a while.

Yes I agree Linux is chaotic.  But I can't stand Windows, because I
hate GUIs (because I can't automate them and my philosophy is to make
the computer work for me, not the other way around).  I know all the
old-fashioned Unix admin commands by heart (I am somewhat dismayed
that the old kill -1 convention for making daemons re-read their config
files seems to have fallen by the wayside!)  My .twmrc is dated 1992.
And PageUp etc work fine in emacs for me :-)

In other words the system will just have command-line access.  In
fact it's supposed to sit in a locked machine room.

Err, to the point... maybe it got lost in the vague generality of the
question.  

My real question is: do kernel threads work on *BSD at all?

I haven't done a proper back to back test but the Debian system
"seems faster" than FreeBSD, running on the same amd64 hardware.

Or perhaps.. crazy question.. can one make a hackintosh/amd64 out of a
16-core machine?

I seem to remember Tony made some (bad) comments about FreeBSD kernel
threads a few months ago...

    Mika

Jay K writes:
>
>ps: Slackware was fine back when I used it. RedHat is ok=2C but it at least=
> used to take forever to do any package management compared to Ubuntu/Debia=
>n.
>Suse has/had RedHat's problem=2C also being rpm basedi but also seemed to l=
>ead in gui/managability.
>
>
>Anyway=2C other than Mac and NT=2C all my other systems are now ssh command=
> line and impossible to do much with. :)
>
>
>ps: I also like *BSD due to the reduced number of choices=2C and the "integ=
>rated build"=2C where you can build a bit
>more in one nice go=2C not just the kernel. Linux is so darn chaotic.
>But I rarely take any advantage of this.
>I would really like=2C whatever I run=2C to build the entire thing from sou=
>rce=2C and do it fairly easily.
>=A0Have the whole thing be debuggable.
>=A0Cross building support would be nice too=2C though lately people seem to=
> give up and use qemu.
>=A0 Too much building stuff wants to run as it builds=2C like using autocon=
>f.
>
>
>=A0- Jay
>
>----------------------------------------
>> From: jay.krell at cornell.edu
>> To: dragisha at m3w.org=3B mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] OS for CM3
>> Date: Sat=2C 22 May 2010 23:35:52 +0000
>>
>>
>> Modula-3 will run on almost anything. Install something we don't work on =
>yet and give me ssh access. :)
>> Like get a Loongson laptop -- comes with Linux/MIPS but can also run Open=
>BSD and maybe others.
>> Or=2C install something we don't have yet in Hudson yet=2C e.g. NetBSD/am=
>d64=2C and have Olaf add jobs for it.
>>
>> Seriously=2C for Hudson purposes=2C NetBSD/amd64 is probably the best=2C =
>followed by NetBSD/x86.
>> I'll set these up eventually.
>>
>>
>> Regarding Linux=2C I've been using Debian=2C because it has about the bes=
>t support for multiple architectures.
>>   And then the same "experience" across all of them -- same installer and=
> package management.
>>
>>
>> Gentoo would be the next or previous choice -- not clear what the ppc64 s=
>upport is in Debian.
>> It helps that I first used wimpy Ubuntu before moving up to the supposedl=
>y manly Debian.
>> Gentoo I've had trouble getting to install+boot.
>>
>>
>> OpenBSD has about the best install experience imho and a certain hard to =
>capture purity about it.
>>   Examples:
>>      NetBSD and FreeBSD support powerpc.
>>      FreeBSD's partitioner doesn't run on powerpc though.
>>      NetBSD I couldn't get to install.
>>      OpenBSD was easy.
>>
>>      Attempting to install Linux or NetBSD on an SGI machine apparently k=
>illed the machine.
>>      I couldn't get either to install or boot. One of them might not have=
> local console working.
>>      But again OpenBSD was easy and worked.
>>
>>
>>     My OpenBSD/sgimips CD was actually bad. But it worked enough to boot=
>=2C and the
>>     the install was then easy to fallback to over the network.
>>
>>
>> But they don't have kernel threads=2C so=2C while we work=2C we probably =
>scale the worst here.
>>   Besides=2C user threads are an /option/ on all Posix systems=2C only /r=
>equired/ on OpenBSD.
>>
>>
>> I think all the user interfaces are terrible though.
>> I am most productive by far on NT=2C using find-in-files countless times =
>daily in Visual C++ 5.0.
>>  It is so much better than command line grep=2C and it beats every other =
>IDE/editor I have tried=2C
>>  and I have tried many. Komodo Edit is so-so. MonoDevelop was promising=
>=2C but it refused
>>  to open *.m3 files as plain text. TextWrangler on Mac is so-so=2C what I=
> use for lack
>>  of anything good. Eclipse is confusing to install and I don't think work=
>ed well=2C but I forget.
>>
>>
>> Mac is distant second in productivity.
>>   At least I don't have to constantly flip the newlines and it has a fast=
> fork.
>>
>>
>> Everything else I can't even edit files on. I can't copy/paste=2C navigat=
>e quickly (e.g. esp. using
>> page up/down/home/end/mouse!). NT also has a fast console with half decen=
>t most support.
>>
>>
>> My most productive pattern is editing on NT and copying files around othe=
>rwise.
>>
>>
>> As well=2C consider that the NT Modula-3 backend is unique and pretty dar=
>n good.
>>   It is fast=2C in-proc=2C and always optimizes a certain amount.
>>   In its only mode=2C it generates significantly better code than unoptim=
>izing gcc.
>>
>>
>>  Compiling N files on NT takes one process to compile=2C codegen=2C write=
> objs files=2C
>> and then another one or two to link.
>>
>>
>> Compiling N files on the other systems takes one process to compile=2C N =
>runs
>> of m3cg to generate N asssembly files=2C N runs to run the assembler.
>>
>>
>> If you really need an *occasional* Posixy experience on NT=2C there is Cy=
>gwin and SFU/SUA.
>> Cygwin has a very slow fork and it is very noticable.
>> SFU/SUA has a "normally" fast fork=2C and it is very noticable.
>>
>>
>> FreeBSD=2C Solaris=2C NetBSD=2C Linux -- should all be about the same.
>>  (ok=2C Solaris/x86 support is only in head=2C not release).
>>
>>
>> Then there are the non-x86 ones=2C like HP-UX=2C OSF/1=2C Irix=2C AIX=2C =
>VMS... :)
>>
>>
>> Also=2C for Hudson purposes=2C we need Java.
>> That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
>> Linux now has good enough Java on all architectures.
>>   There was a project to eliminate all the assembly code. And we have no =
>problem
>>     e.g. now on Linux/sparc and Linux/powerpc.
>>
>> All the commercial systems probably suffice also.
>>
>>  - Jay
>>
>> ----------------------------------------
>>> From: dragisha at m3w.org
>>> To: mika at async.async.caltech.edu
>>> Date: Sun=2C 23 May 2010 00:32:25 +0200
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] OS for CM3
>>>
>>> There is no simple nor unique answer to this. I prefer Fedora=2C and I'v=
>e
>>> been using RedHat since 1996... Some people prefer RHEL=2C or CentOS if
>>> they like it freer. Jumped of SLS then Slackware I've been using from
>>> 1993-1995=2C and never looked back.
>>>
>>> Easy to administer and maintain=2C most of modern distros have GUI for
>>> every admin task.
>>>
>>> On Sat=2C 2010-05-22 at 14:53 -0700=2C Mika Nystrom wrote:
>>>> Hi Modula-3ers=2C
>>>>
>>>> Can anyone give me some advice on what OS to install on a new PC comput=
>e
>>>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
>>>> to be running is all written in Modula-3 with some C and Fortran thrown
>>>> in and I want to use CM3. The odd extra thing in Java and some analysis
>>>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
>>>>
>>>> I've always liked the ease of administration (i.e.=2C I'm an old dog an=
>d I
>>>> don't have to learn anything new) of FreeBSD=2C but the threading suppo=
>rt
>>>> seems much better with Linux? I do really want to run multi-threaded
>>>> programs across several CPUs.
>>>>
>>>> I am considering Debian/amd64. Any other recommendations=2C experiences=
>?
>>>>
>>>> Mika
>>>
>>> --
>>> Dragi=B9a Duri=E6
>>>
>>
> 		 	   		  =


From mika at async.async.caltech.edu  Sun May 23 02:13:49 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Sat, 22 May 2010 17:13:49 -0700
Subject: [M3devel] OS for CM3
In-Reply-To: <COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl> 
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
	<COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl>
Message-ID: <20100523001349.DCCE81A2096@async.async.caltech.edu>

Jay K writes:
>
>Modula-3 will run on almost anything. Install something we don't work on ye=
>t and give me ssh access. :)

Speaking of which, how's ALPHAOSF1 doing?  I'm trying to get a project
started that might involve Alphas...

   Mika


From jay.krell at cornell.edu  Sun May 23 03:06:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 23 May 2010 01:06:22 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <20100523001349.DCCE81A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>, ,
	<1274567545.29716.4.camel@localhost>,
	<COL101-W19F97EB48F73BB071C718DE6E50@phx.gbl>,
	<20100523001349.DCCE81A2096@async.async.caltech.edu>
Message-ID: <COL101-W109BCFDBACAB678FB55CDAE6E60@phx.gbl>

I haven't set up any of my Alphas yet. Ssh access to yours? :)

 - Jay

> To: jay.krell at cornell.edu
> Date: Sat, 22 May 2010 17:13:49 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] OS for CM3
> 
> Jay K writes:
> >
> >Modula-3 will run on almost anything. Install something we don't work on ye=
> >t and give me ssh access. :)
> 
> Speaking of which, how's ALPHAOSF1 doing?  I'm trying to get a project
> started that might involve Alphas...
> 
>    Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100523/740d91b1/attachment-0002.html>

From jay.krell at cornell.edu  Sun May 23 03:49:07 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 23 May 2010 01:49:07 +0000
Subject: [M3devel] OS for CM3
In-Reply-To: <20100523000849.BA8E61A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>,
	<1274567545.29716.4.camel@localhost>
	<COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>,
	<20100523000849.BA8E61A2096@async.async.caltech.edu>
Message-ID: <COL101-W1561F238322CDB78B1CE53E6E60@phx.gbl>

FreeBSD is ok, NetBSD prob ok, not tested as much. OpenBSD not good.

 - Jay

> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] OS for CM3 
> Date: Sat, 22 May 2010 17:08:49 -0700
> From: mika at async.async.caltech.edu
> 
> Well I know all about the various OS tradeoffs, I was asking more
> about Modula-3 itself.
> 
> I want to use kernel threads, so I can share large data structures 
> across CPUs.  This is for production work, not a development platform.
> My main development platform will probably stay FreeBSD/i386 for a while.
> 
> Yes I agree Linux is chaotic.  But I can't stand Windows, because I
> hate GUIs (because I can't automate them and my philosophy is to make
> the computer work for me, not the other way around).  I know all the
> old-fashioned Unix admin commands by heart (I am somewhat dismayed
> that the old kill -1 convention for making daemons re-read their config
> files seems to have fallen by the wayside!)  My .twmrc is dated 1992.
> And PageUp etc work fine in emacs for me :-)
> 
> In other words the system will just have command-line access.  In
> fact it's supposed to sit in a locked machine room.
> 
> Err, to the point... maybe it got lost in the vague generality of the
> question.  
> 
> My real question is: do kernel threads work on *BSD at all?
> 
> I haven't done a proper back to back test but the Debian system
> "seems faster" than FreeBSD, running on the same amd64 hardware.
> 
> Or perhaps.. crazy question.. can one make a hackintosh/amd64 out of a
> 16-core machine?
> 
> I seem to remember Tony made some (bad) comments about FreeBSD kernel
> threads a few months ago...
> 
>     Mika
> 
> Jay K writes:
> >
> >ps: Slackware was fine back when I used it. RedHat is ok=2C but it at least=
> > used to take forever to do any package management compared to Ubuntu/Debia=
> >n.
> >Suse has/had RedHat's problem=2C also being rpm basedi but also seemed to l=
> >ead in gui/managability.
> >
> >
> >Anyway=2C other than Mac and NT=2C all my other systems are now ssh command=
> > line and impossible to do much with. :)
> >
> >
> >ps: I also like *BSD due to the reduced number of choices=2C and the "integ=
> >rated build"=2C where you can build a bit
> >more in one nice go=2C not just the kernel. Linux is so darn chaotic.
> >But I rarely take any advantage of this.
> >I would really like=2C whatever I run=2C to build the entire thing from sou=
> >rce=2C and do it fairly easily.
> >=A0Have the whole thing be debuggable.
> >=A0Cross building support would be nice too=2C though lately people seem to=
> > give up and use qemu.
> >=A0 Too much building stuff wants to run as it builds=2C like using autocon=
> >f.
> >
> >
> >=A0- Jay
> >
> >----------------------------------------
> >> From: jay.krell at cornell.edu
> >> To: dragisha at m3w.org=3B mika at async.async.caltech.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: RE: [M3devel] OS for CM3
> >> Date: Sat=2C 22 May 2010 23:35:52 +0000
> >>
> >>
> >> Modula-3 will run on almost anything. Install something we don't work on =
> >yet and give me ssh access. :)
> >> Like get a Loongson laptop -- comes with Linux/MIPS but can also run Open=
> >BSD and maybe others.
> >> Or=2C install something we don't have yet in Hudson yet=2C e.g. NetBSD/am=
> >d64=2C and have Olaf add jobs for it.
> >>
> >> Seriously=2C for Hudson purposes=2C NetBSD/amd64 is probably the best=2C =
> >followed by NetBSD/x86.
> >> I'll set these up eventually.
> >>
> >>
> >> Regarding Linux=2C I've been using Debian=2C because it has about the bes=
> >t support for multiple architectures.
> >>   And then the same "experience" across all of them -- same installer and=
> > package management.
> >>
> >>
> >> Gentoo would be the next or previous choice -- not clear what the ppc64 s=
> >upport is in Debian.
> >> It helps that I first used wimpy Ubuntu before moving up to the supposedl=
> >y manly Debian.
> >> Gentoo I've had trouble getting to install+boot.
> >>
> >>
> >> OpenBSD has about the best install experience imho and a certain hard to =
> >capture purity about it.
> >>   Examples:
> >>      NetBSD and FreeBSD support powerpc.
> >>      FreeBSD's partitioner doesn't run on powerpc though.
> >>      NetBSD I couldn't get to install.
> >>      OpenBSD was easy.
> >>
> >>      Attempting to install Linux or NetBSD on an SGI machine apparently k=
> >illed the machine.
> >>      I couldn't get either to install or boot. One of them might not have=
> > local console working.
> >>      But again OpenBSD was easy and worked.
> >>
> >>
> >>     My OpenBSD/sgimips CD was actually bad. But it worked enough to boot=
> >=2C and the
> >>     the install was then easy to fallback to over the network.
> >>
> >>
> >> But they don't have kernel threads=2C so=2C while we work=2C we probably =
> >scale the worst here.
> >>   Besides=2C user threads are an /option/ on all Posix systems=2C only /r=
> >equired/ on OpenBSD.
> >>
> >>
> >> I think all the user interfaces are terrible though.
> >> I am most productive by far on NT=2C using find-in-files countless times =
> >daily in Visual C++ 5.0.
> >>  It is so much better than command line grep=2C and it beats every other =
> >IDE/editor I have tried=2C
> >>  and I have tried many. Komodo Edit is so-so. MonoDevelop was promising=
> >=2C but it refused
> >>  to open *.m3 files as plain text. TextWrangler on Mac is so-so=2C what I=
> > use for lack
> >>  of anything good. Eclipse is confusing to install and I don't think work=
> >ed well=2C but I forget.
> >>
> >>
> >> Mac is distant second in productivity.
> >>   At least I don't have to constantly flip the newlines and it has a fast=
> > fork.
> >>
> >>
> >> Everything else I can't even edit files on. I can't copy/paste=2C navigat=
> >e quickly (e.g. esp. using
> >> page up/down/home/end/mouse!). NT also has a fast console with half decen=
> >t most support.
> >>
> >>
> >> My most productive pattern is editing on NT and copying files around othe=
> >rwise.
> >>
> >>
> >> As well=2C consider that the NT Modula-3 backend is unique and pretty dar=
> >n good.
> >>   It is fast=2C in-proc=2C and always optimizes a certain amount.
> >>   In its only mode=2C it generates significantly better code than unoptim=
> >izing gcc.
> >>
> >>
> >>  Compiling N files on NT takes one process to compile=2C codegen=2C write=
> > objs files=2C
> >> and then another one or two to link.
> >>
> >>
> >> Compiling N files on the other systems takes one process to compile=2C N =
> >runs
> >> of m3cg to generate N asssembly files=2C N runs to run the assembler.
> >>
> >>
> >> If you really need an *occasional* Posixy experience on NT=2C there is Cy=
> >gwin and SFU/SUA.
> >> Cygwin has a very slow fork and it is very noticable.
> >> SFU/SUA has a "normally" fast fork=2C and it is very noticable.
> >>
> >>
> >> FreeBSD=2C Solaris=2C NetBSD=2C Linux -- should all be about the same.
> >>  (ok=2C Solaris/x86 support is only in head=2C not release).
> >>
> >>
> >> Then there are the non-x86 ones=2C like HP-UX=2C OSF/1=2C Irix=2C AIX=2C =
> >VMS... :)
> >>
> >>
> >> Also=2C for Hudson purposes=2C we need Java.
> >> That actually rules out a lot -- basically any *BSD that isn't x86/amd64.
> >> Linux now has good enough Java on all architectures.
> >>   There was a project to eliminate all the assembly code. And we have no =
> >problem
> >>     e.g. now on Linux/sparc and Linux/powerpc.
> >>
> >> All the commercial systems probably suffice also.
> >>
> >>  - Jay
> >>
> >> ----------------------------------------
> >>> From: dragisha at m3w.org
> >>> To: mika at async.async.caltech.edu
> >>> Date: Sun=2C 23 May 2010 00:32:25 +0200
> >>> CC: m3devel at elegosoft.com
> >>> Subject: Re: [M3devel] OS for CM3
> >>>
> >>> There is no simple nor unique answer to this. I prefer Fedora=2C and I'v=
> >e
> >>> been using RedHat since 1996... Some people prefer RHEL=2C or CentOS if
> >>> they like it freer. Jumped of SLS then Slackware I've been using from
> >>> 1993-1995=2C and never looked back.
> >>>
> >>> Easy to administer and maintain=2C most of modern distros have GUI for
> >>> every admin task.
> >>>
> >>> On Sat=2C 2010-05-22 at 14:53 -0700=2C Mika Nystrom wrote:
> >>>> Hi Modula-3ers=2C
> >>>>
> >>>> Can anyone give me some advice on what OS to install on a new PC comput=
> >e
> >>>> server with 16 to 24 cores and 16 to 32 GB of RAM? The code I'm going
> >>>> to be running is all written in Modula-3 with some C and Fortran thrown
> >>>> in and I want to use CM3. The odd extra thing in Java and some analysis
> >>>> in R. Currently I'm stuck with PM3 on FreeBSD/i386.
> >>>>
> >>>> I've always liked the ease of administration (i.e.=2C I'm an old dog an=
> >d I
> >>>> don't have to learn anything new) of FreeBSD=2C but the threading suppo=
> >rt
> >>>> seems much better with Linux? I do really want to run multi-threaded
> >>>> programs across several CPUs.
> >>>>
> >>>> I am considering Debian/amd64. Any other recommendations=2C experiences=
> >?
> >>>>
> >>>> Mika
> >>>
> >>> --
> >>> Dragi=B9a Duri=E6
> >>>
> >>
> > 		 	   		  =
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100523/c9ebf99a/attachment-0002.html>

From dragisha at m3w.org  Sun May 23 04:14:25 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 23 May 2010 04:14:25 +0200
Subject: [M3devel] ***SPAM*** RE:  OS for CM3
In-Reply-To: <COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
	,<1274567545.29716.4.camel@localhost>
	<COL101-W60FC3EFF2DCD98A182855FE6E50@phx.gbl>
Message-ID: <1274580865.29716.6.camel@localhost>

And of course .deb is superior to .rpm.. Ok, you win! :)

RedHat package management compared do Fedora's yum is Stone Age. Also -
yum supports multiarch nicely, as does rpm it's based on.

On Sat, 2010-05-22 at 23:40 +0000, Jay K wrote:
> 
> ps: Slackware was fine back when I used it. RedHat is ok, but it at
> least used to take forever to do any package management compared to
> Ubuntu/Debian.
> Suse has/had RedHat's problem, also being rpm basedi but also seemed
> to lead in gui/managability.
> 
> 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From dabenavidesd at yahoo.es  Tue May 25 06:07:24 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 25 May 2010 04:07:24 +0000 (GMT)
Subject: [M3devel] OS for CM3
In-Reply-To: <20100522215317.E428D1A2096@async.async.caltech.edu>
Message-ID: <729398.10895.qm@web23605.mail.ird.yahoo.com>

Hi:
if easy of administration is what you are looking for maybe a bsd flavour a is the right choice of use probably it would be a linux distro but a common sense of easy administration and use like ubuntu rh/centos server or why not a gentoo or archlinux if customization is what you want to add more cores linux will support up to 1024 and the small or medium size servers are commonly used in this servers sizes I guess you have a good choice to take advantage, how many does support Win server 2k3 (up to 64?) an another bsd up to how many?  

Hope it helps, thanks in advance

--- El s?b, 22/5/10, Mika Nystrom <mika at async.async.caltech.edu> escribi?:

> De: Mika Nystrom <mika at async.async.caltech.edu>
> Asunto: [M3devel] OS for CM3
> Para: m3devel at elegosoft.com
> Fecha: s?bado, 22 de mayo, 2010 16:53
> Hi Modula-3ers,
> 
> Can anyone give me some advice on what OS to install on a
> new PC compute
> server with 16 to 24 cores and 16 to 32 GB of RAM? 
> The code I'm going
> to be running is all written in Modula-3 with some C and
> Fortran thrown
> in and I want to use CM3.  The odd extra thing in Java
> and some analysis
> in R.  Currently I'm stuck with PM3 on FreeBSD/i386.
> 
> I've always liked the ease of administration (i.e., I'm an
> old dog and I
> don't have to learn anything new) of FreeBSD, but the
> threading support
> seems much better with Linux?  I do really want to run
> multi-threaded
> programs across several CPUs.
> 
> I am considering Debian/amd64.  Any other
> recommendations, experiences?
> 
>     Mika
> 


      


From jay.krell at cornell.edu  Wed May 26 07:58:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 05:58:54 +0000
Subject: [M3devel] separate directory for gcc-4.5? import binutils?
Message-ID: <COL101-W500D7CADC89644958BFA09E6E90@phx.gbl>


Anyone object if I create gcc-4.5.0 or gcc-4.5 next to m3cc/gcc?
Anyone object if I import binutils?

Both are tenuous but possibly useful.


Importing gcc-4.5.0 allows for an easier/slower move to it, with somewhat easier to read history.

?- m3cc/src/m3makefile could chose between gcc and gcc-4.5.0. 
?? As they are tested they could move to gcc-4.5.0.

?- The original import wouldn't have the Modula-3 diffs.
?? It might be possible to have CVS do the future merges.
?? At least maybe to 4.5.1, 4.5.2, etc.
?? Which is a reason to call it 4.5.

?- But it does add considerably to the source tree size and time to cvs checkout/upd.

?- We'd probably want to symlink gmp/mpfr, and now mpc.
?? Really those should probably be *not* under gcc, but outside,
?? build them first, point gcc at them the "same" way it would.
?? Point being
???? - more granular "clean"
???? - split up the tree in terms of history/import/sharing 


Importing binutils might kinda/sorta allow better cross support.
gcc+binutils are 2 out of 3 pieces need to build every complete cross tools.
The third piece is headers/libraries for each system.


One can at least assemble the assembly to object files.


Or not. I can also merge our changes into 4.5.0, test a few but not all targets, and go.
e.g. Darwin/amd64, Linux/x86, Solaris/sparc32.
?

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Wed May 26 08:05:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 06:05:25 +0000
Subject: [M3devel] m3cc static chain stuff
Message-ID: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>


Can any of this be removed?
Can we really not just use "unfold-nested-procs" like NT386?
We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
generally a considered the responsibility of optimizers.

Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
Maybe I'll try without.


diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
--- /src/orig/gcc-4.3.0/gcc/tree-nested.c??? 2008-02-15 09:36:43.000000000 -0800
+++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c??? 2010-05-09 22:27:58.000000000 -0700


-/* Build or return the RECORD_TYPE that describes the frame state that is
-?? shared between INFO->CONTEXT and its nested functions.? This record will
-?? not be complete until finalize_nesting_tree; up until that point we'll
+/* This must agree with the string defined by the same name in m3gdb, file
+?? m3-util.c */ 
+static const char * nonlocal_var_rec_name = "_nonlocal_var_rec"; 
+
+/* Build or return the RECORD_TYPE that describes the non-local frame struct 
+?? that is shared between INFO->CONTEXT and its nested functions.? This record 
+?? will not be complete until finalize_nesting_tree; up until that point we'll
??? be adding fields as necessary.
?
??? We also build the DECL that represents this frame in the function.? */
@@ -209,7 +224,8 @@
?????? free (name);
?
?????? info->frame_type = type;
-????? info->frame_decl = create_tmp_var_for (info, type, "FRAME");
+????? info->frame_decl 
+??????? = create_tmp_var_for (info, type, nonlocal_var_rec_name);
?
?????? /* ??? Always make it addressable for now, since it is meant to
???? ?be pointed to by the static chain pointer.? This pessimizes
@@ -218,6 +234,8 @@
???? ?reachable, but the true pessimization is to create the non-
???? ?local frame structure in the first place.? */
?????? TREE_ADDRESSABLE (info->frame_decl) = 1;
+????? /* m3gdb needs to know about this variable. */ 
+????? DECL_IGNORED_P (info->frame_decl) = 0;? 
???? }
?? return type;
?}
@@ -290,6 +308,10 @@
?? return *slot;
?}
?
+/* This must agree with the string defined by the same name in m3gdb, file
+?? m3_util.c */ 
+static const char * static_link_var_name = "_static_link_var"; 
+
?/* Build or return the variable that holds the static chain within
??? INFO->CONTEXT.? This variable may only be used within INFO->CONTEXT.? */
?
@@ -310,9 +332,14 @@
???? ?Note also that it's represented as a parameter.? This is more
???? ?close to the truth, since the initial value does come from 
???? ?the caller.? */
-????? decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
+????? decl = build_decl 
+?????????????? (PARM_DECL, get_identifier (static_link_var_name), type);
+????? TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */ 
?????? DECL_ARTIFICIAL (decl) = 1;
-????? DECL_IGNORED_P (decl) = 1;
+
+????? /* m3gdb needs to know about this variable. */ 
+????? DECL_IGNORED_P (decl) = 0;
+
?????? TREE_USED (decl) = 1;
?????? DECL_CONTEXT (decl) = info->context;
?????? DECL_ARG_TYPE (decl) = type;
@@ -326,7 +353,11 @@
?? return decl;
?}
?
-/* Build or return the field within the non-local frame state that holds
+/* This must agree with the string defined by the same name in m3gdb, file
+?? m3_util.c */ 
+static const char * static_link_copy_field_name = "_static_link_copy_field"; 
+
+/* Build or return the field within the non-local frame struct that holds
??? the static chain for INFO->CONTEXT.? This is the way to walk back up
??? multiple nesting levels.? */
?
@@ -339,10 +370,12 @@
?????? tree type = build_pointer_type (get_frame_type (info->outer));
?
?????? field = make_node (FIELD_DECL);
-????? DECL_NAME (field) = get_identifier ("__chain");
+????? DECL_NAME (field) = get_identifier (static_link_copy_field_name);
?????? TREE_TYPE (field) = type;
?????? DECL_ALIGN (field) = TYPE_ALIGN (type);
?????? DECL_NONADDRESSABLE_P (field) = 1;
+????? /* m3gdb should know about this field. */ 
+????? DECL_IGNORED_P (field) = 0;? 
?
?????? insert_field_into_struct (get_frame_type (info), field);
?
@@ -465,7 +498,7 @@
?? return *slot;
?} 
?
-/* Build or return the field within the non-local frame state that holds
+/* Build or return the field within the non-local frame struct that holds
??? the non-local goto "jmp_buf".? The buffer itself is maintained by the
??? rtl middle-end as dynamic stack space is allocated.? */
?
@@ -1620,6 +1653,9 @@
?? switch (TREE_CODE (t))
???? {
???? case ADDR_EXPR:
+????? if (TREE_STATIC (t))
+??? break;
+
?????? /* Build
???? ?? T.1 = &CHAIN->tramp;
???? ?? T.2 = __builtin_adjust_trampoline (T.1);
@@ -1714,6 +1750,22 @@
???? }
?????? break;
?
+??? case STATIC_CHAIN_EXPR:
+????? decl = TREE_OPERAND (t, 0);
+????? target_context = decl_function_context (decl);
+????? if (target_context)
+??? {
+??? ? if (info->context == target_context)
+??? ??? {
+??? ????? /* Make sure frame_decl gets created.? */
+??? ????? (void) get_frame_type (info);
+??? ??? }
+??? ? *tp = get_static_chain (info, target_context, &wi->tsi);
+??? }
+????? else
+??? *tp = null_pointer_node;
+????? break;
+
???? case RETURN_EXPR:
???? case GIMPLE_MODIFY_STMT:
???? case WITH_SIZE_EXPR:
@@ -1768,13 +1820,22 @@
?? return NULL_TREE;
?}
?
+static bool
+debug_static_links (void) 
+{ return
+??? write_symbols != NO_DEBUG
+??? && debug_info_level != DINFO_LEVEL_NONE
+??? && debug_info_level != DINFO_LEVEL_TERSE;
+
+} /* debug_static_links */ 
+
?/* Walk the nesting tree starting with ROOT, depth first.? Convert all
??? trampolines and call expressions.? On the way back up, determine if
??? a nested function actually uses its static chain; if not, remember that.? */
?
?static void
?convert_all_function_calls (struct nesting_info *root)
-{
+{ 
?? do
???? {
?????? if (root->inner)
@@ -1784,7 +1845,10 @@
?????? walk_function (convert_call_expr, root);
?
?????? /* If the function does not use a static chain, then remember that.? */
-????? if (root->outer && !root->chain_decl && !root->chain_field)
+????? if (root->outer && !root->chain_decl && !root->chain_field
+/* REMOVE ME: */ 
+????????? /* && !debug_static_links () */ 
+???????? )
???? DECL_NO_STATIC_CHAIN (root->context) = 1;
?????? else
???? gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
@@ -1806,6 +1870,21 @@
?? tree context = root->context;
?? struct function *sf;
?
+/* REMOVEME: */ 
+? /* If this is a nested function and we are supporting debugging via
+???? m3gdb, we always need a chain_decl, so m3gdb can find the static 
+???? chain, even if the programmer's code doesn't use it. */ 
+? if (false && root->outer && debug_static_links () )
+??? { tree static_chain_decl, temp, stmt;
+????? /* This is a desperate attempt to get later code generation to 
+???????? store the static link.? If it works, it'll be a miracle. */ 
+????? static_chain_decl = get_chain_decl (root); 
+????? stmt = build_addr (static_chain_decl, root->context); 
+????? temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
+????? stmt = build_gimple_modify_stmt (temp, static_chain_decl);
+????? append_to_statement_list (stmt, &stmt_list);
+??? } 
+
?? /* If we created a non-local frame type or decl, we need to lay them
????? out at this time.? */
?? if (root->frame_type)
@@ -1912,7 +1991,7 @@
????? proper BIND_EXPR.? */
?? if (root->new_local_var_chain)
???? declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
-??? ??? ? false);
+??? ??? ? true);
?? if (root->debug_var_chain)
???? declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
???? ??? ? true);


 		 	   		  

From jay.krell at cornell.edu  Wed May 26 09:50:40 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 07:50:40 +0000
Subject: [M3devel] newer versions might obviate some of our changes
Message-ID: <COL101-W329B816AD3C1C3C5DBD3DE6E90@phx.gbl>


I haven't tracked down everything, but in a few cases, I notice that functions we modified
are removed. It appears we might have been fixing bugs that got fixed by gcc later.

Here is an example:

We changed mark_non_addressable in tree-ssa-alias.c.

First it changed to something else:

2008-06-04? Richard Guenther? <rguenther at suse.de>

??? * tree-flow-inline.h (is_global_var): Do not check TREE_STATIC on MTAGs.
??? (is_call_clobbered): Always check var_ann->call_clobbered.
??? (mark_call_clobbered): Always set var_ann->call_clobbered.
??? (clear_call_clobbered): Always clear var_ann->call_clobbered.
??? * tree-ssa-alias.c (mark_non_addressable): Use clear_call_clobbered.


then that something else got removed:


2009-04-03? Richard Guenther? <rguenther at suse.de>

??? PR middle-end/13146
??? PR tree-optimization/23940
... many ..
??? * tree-flow-inline.h (gimple_aliases_computed_p,
??? gimple_addressable_vars, gimple_call_clobbered_vars,
??? gimple_call_used_vars, gimple_global_var, may_aliases, memory_partition,
??? factoring_name_p, mark_call_clobbered, clear_call_clobbered,
??? compare_ssa_operands_equal, symbol_mem_tag, set_symbol_mem_tag,
??? gimple_mem_ref_stats): Remove.


In tree-cfg.c, we modified remove_useless_stmts_bind:

????? /* Removing the BIND_EXPR will break Modula-3 debug information by? 
???????? making explicitly programmed blocks disappear. */ 
????? && ( write_symbols == NO_DEBUG
?????????? || debug_info_level == DINFO_LEVEL_NONE
?????????? || debug_info_level == DINFO_LEVEL_TERSE ))


the change seems dubious to me -- generating symbols should NOT change codegen.

Anyway, this function and a lot around it is gone now:


2009-10-08? Michael Matz? <matz at suse.de>

??? PR middle-end/41573
...
??? * tree-cfg.c (struct rus_data, remove_useless_stmts_warn_notreached,
??? remove_useless_stmts_cond, remove_useless_stmts_tf,
??? remove_useless_stmts_tc, remove_useless_stmts_bind,
??? remove_useless_stmts_goto, remove_useless_stmts_label,
??? remove_useless_stmts_1, remove_useless_stmts,
??? pass_remove_useless_stmts): Remove.


also, some of the OpenBSD patches got applied, at least x86 and sparc64.
Not clear about powerpc and amd64. (maybe amd64 is x86 -m64? powerpc
definitely seems to be missing).


I should look more closely, see if they were fixing something similar to what we were
and make sure they didn't just move the problem elsewhere.


Later,
?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 09:55:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 07:55:19 +0000
Subject: [M3devel] m3cc static chain stuff
Message-ID: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>


I'm going to try to keep the code that seems to do anything, however:

1) if (false && 

?I plan to remove that.


2)
+????? if (root->outer && !root->chain_decl && !root->chain_field
+/* REMOVE ME: */ 
+????????? /* && !debug_static_links () */ 
+???????? )


I can't find where that would apply, and it is commented out anyway so I'll remove it.


I'm open to arguments though. :)

dbxout.c
+#if 0
+/* Code copied from 1.4.2.2: */ 


I can cheaply enough keep that...should we really though?


I really think we can reduce our changes.
Enough type information should be passed around so that regular gdb works. Imho.
?And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
? don't cause internal compiler errors. So that debug info might be generated on systems
? that don't support stabs though granted they are few and minor (hppa64-hpux).
Nested functions should be transformed to not be nested. Imho.
Optimization should be allowed to inhibit debugging as much as it does for any other language.


I realize the type information getting around is probably a lot of work.
And it is needed in m3back also, and probably not shared work.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: m3cc static chain stuff
> Date: Wed, 26 May 2010 06:05:25 +0000
>
>
> Can any of this be removed?
> Can we really not just use "unfold-nested-procs" like NT386?
> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
> generally a considered the responsibility of optimizers.
>
> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
> Maybe I'll try without.
>
>
> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
>
>
> -/* Build or return the RECORD_TYPE that describes the frame state that is
> -   shared between INFO->CONTEXT and its nested functions.  This record will
> -   not be complete until finalize_nesting_tree; up until that point we'll
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3-util.c */
> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
> +
> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
> +   that is shared between INFO->CONTEXT and its nested functions.  This record
> +   will not be complete until finalize_nesting_tree; up until that point we'll
>     be adding fields as necessary.
>
>     We also build the DECL that represents this frame in the function.  */
> @@ -209,7 +224,8 @@
>        free (name);
>
>        info->frame_type = type;
> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
> +      info->frame_decl
> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>
>        /* ??? Always make it addressable for now, since it is meant to
>       be pointed to by the static chain pointer.  This pessimizes
> @@ -218,6 +234,8 @@
>       reachable, but the true pessimization is to create the non-
>       local frame structure in the first place.  */
>        TREE_ADDRESSABLE (info->frame_decl) = 1;
> +      /* m3gdb needs to know about this variable. */
> +      DECL_IGNORED_P (info->frame_decl) = 0;
>      }
>    return type;
>  }
> @@ -290,6 +308,10 @@
>    return *slot;
>  }
>
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */
> +static const char * static_link_var_name = "_static_link_var";
> +
>  /* Build or return the variable that holds the static chain within
>     INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>
> @@ -310,9 +332,14 @@
>       Note also that it's represented as a parameter.  This is more
>       close to the truth, since the initial value does come from
>       the caller.  */
> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
> +      decl = build_decl
> +               (PARM_DECL, get_identifier (static_link_var_name), type);
> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>        DECL_ARTIFICIAL (decl) = 1;
> -      DECL_IGNORED_P (decl) = 1;
> +
> +      /* m3gdb needs to know about this variable. */
> +      DECL_IGNORED_P (decl) = 0;
> +
>        TREE_USED (decl) = 1;
>        DECL_CONTEXT (decl) = info->context;
>        DECL_ARG_TYPE (decl) = type;
> @@ -326,7 +353,11 @@
>    return decl;
>  }
>
> -/* Build or return the field within the non-local frame state that holds
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */
> +static const char * static_link_copy_field_name = "_static_link_copy_field";
> +
> +/* Build or return the field within the non-local frame struct that holds
>     the static chain for INFO->CONTEXT.  This is the way to walk back up
>     multiple nesting levels.  */
>
> @@ -339,10 +370,12 @@
>        tree type = build_pointer_type (get_frame_type (info->outer));
>
>        field = make_node (FIELD_DECL);
> -      DECL_NAME (field) = get_identifier ("__chain");
> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>        TREE_TYPE (field) = type;
>        DECL_ALIGN (field) = TYPE_ALIGN (type);
>        DECL_NONADDRESSABLE_P (field) = 1;
> +      /* m3gdb should know about this field. */
> +      DECL_IGNORED_P (field) = 0;
>
>        insert_field_into_struct (get_frame_type (info), field);
>
> @@ -465,7 +498,7 @@
>    return *slot;
>  }
>
> -/* Build or return the field within the non-local frame state that holds
> +/* Build or return the field within the non-local frame struct that holds
>     the non-local goto "jmp_buf".  The buffer itself is maintained by the
>     rtl middle-end as dynamic stack space is allocated.  */
>
> @@ -1620,6 +1653,9 @@
>    switch (TREE_CODE (t))
>      {
>      case ADDR_EXPR:
> +      if (TREE_STATIC (t))
> +    break;
> +
>        /* Build
>         T.1 = &CHAIN->tramp;
>         T.2 = __builtin_adjust_trampoline (T.1);
> @@ -1714,6 +1750,22 @@
>      }
>        break;
>
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
>      case RETURN_EXPR:
>      case GIMPLE_MODIFY_STMT:
>      case WITH_SIZE_EXPR:
> @@ -1768,13 +1820,22 @@
>    return NULL_TREE;
>  }
>
> +static bool
> +debug_static_links (void)
> +{ return
> +    write_symbols != NO_DEBUG
> +    && debug_info_level != DINFO_LEVEL_NONE
> +    && debug_info_level != DINFO_LEVEL_TERSE;
> +
> +} /* debug_static_links */
> +
>  /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>     trampolines and call expressions.  On the way back up, determine if
>     a nested function actually uses its static chain; if not, remember that.  */
>
>  static void
>  convert_all_function_calls (struct nesting_info *root)
> -{
> +{
>    do
>      {
>        if (root->inner)
> @@ -1784,7 +1845,10 @@
>        walk_function (convert_call_expr, root);
>
>        /* If the function does not use a static chain, then remember that.  */
> -      if (root->outer && !root->chain_decl && !root->chain_field)
> +      if (root->outer && !root->chain_decl && !root->chain_field
> +/* REMOVE ME: */
> +          /* && !debug_static_links () */
> +         )
>      DECL_NO_STATIC_CHAIN (root->context) = 1;
>        else
>      gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
> @@ -1806,6 +1870,21 @@
>    tree context = root->context;
>    struct function *sf;
>
> +/* REMOVEME: */
> +  /* If this is a nested function and we are supporting debugging via
> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
> +     chain, even if the programmer's code doesn't use it. */
> +  if (false && root->outer && debug_static_links () )
> +    { tree static_chain_decl, temp, stmt;
> +      /* This is a desperate attempt to get later code generation to
> +         store the static link.  If it works, it'll be a miracle. */
> +      static_chain_decl = get_chain_decl (root);
> +      stmt = build_addr (static_chain_decl, root->context);
> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
> +      append_to_statement_list (stmt, &stmt_list);
> +    }
> +
>    /* If we created a non-local frame type or decl, we need to lay them
>       out at this time.  */
>    if (root->frame_type)
> @@ -1912,7 +1991,7 @@
>       proper BIND_EXPR.  */
>    if (root->new_local_var_chain)
>      declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
> -          false);
> +          true);
>    if (root->debug_var_chain)
>      declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>            true);
>
>
>
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 13:58:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 11:58:09 +0000
Subject: [M3devel] dbxout_static_chain_decl?
Message-ID: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>


Rodney, you added this function, along with a comment that says it doesn't actually work.
Does it work?
Does it accomplish anything?
Can I remove it and its calls?

/* Special-purpose function to write stabs for the static_chain_decl. 
?? So far, this is not working.? m3gdb needs the place in the activation
?? record where the SL is stored.? Right now, the SL is not necessarily
?? stored at all, but may just be kept in a register.? DECL_RTL and 
?? DECL_INCOMING_RTL may both have register expressions.? But stabs
?? entries for register variables, of kind N_RSYM, are currently ignored
?? by gdb in dbxread.c, and making it read them could create problems
?? elsewhere, because there can be other variables for which both an
?? N_RSYM and an N_LSYM stabs entry are created.?? 
*/ 
static int 
dbxout_static_chain_decl (tree decl) 

It was added 19 months ago by:
? http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9

as well, do we need the #if 0 code added then?

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 16:20:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 14:20:04 +0000
Subject: [M3devel] DECL_LANG_SPECIFIC and casts?
Message-ID: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>


Tony, this thing where we do:

? DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
...

????? tree var = (tree)DECL_LANG_SPECIFIC(index);


Is this running afoul of the gcc garbage collector?
? Seems likely.

And does it matter?
? Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
?assuming m3_write_globals is called near the end.


Thing is:
struct lang_identifier GTY(()) ...
union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
struct lang_type GTY(()) ...
typedef struct lang_decl GTY(()) ...
struct language_function GTY(()) ...


Which are nearly unused, cause me grief.
They have to be different for 4.5 vs. 4.2/4.3.
? Just the GTY needs to be moved to before the union/struct tag.


I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
? I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
?? aren't so small like ours so I'd rather not.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Wed May 26 16:26:32 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 26 May 2010 10:26:32 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>
References: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>
Message-ID: <88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>

On 26 May 2010, at 03:55, Jay K wrote:

> 
> I'm going to try to keep the code that seems to do anything, however:
> 
> 1) if (false && 
> 
>  I plan to remove that.
> 
> 
> 2)
> +      if (root->outer && !root->chain_decl && !root->chain_field
> +/* REMOVE ME: */ 
> +          /* && !debug_static_links () */ 
> +         )
> 
> 
> I can't find where that would apply, and it is commented out anyway so I'll remove it.
> 
> 
> I'm open to arguments though. :)
> 
> dbxout.c
> +#if 0
> +/* Code copied from 1.4.2.2: */ 
> 
> 
> I can cheaply enough keep that...should we really though?
> 
> 
> I really think we can reduce our changes.
> Enough type information should be passed around so that regular gdb works. Imho.

Possibly, but M3 has a very different notion of type to C.  Moreover, it is extremely valuable to have the M3 type ids there so that functionality can map back to the types in the M3 runtime system.  It would be possible to implement much of the m3gdb debugging support by calling back into the language run-time passing the language type ids instead of relying on hand-crafted C in m3gdb.  But I agree that more type information would be good, particularly for records.

>  And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
>   don't cause internal compiler errors. So that debug info might be generated on systems
>   that don't support stabs though granted they are few and minor (hppa64-hpux).
> Nested functions should be transformed to not be nested. Imho.

I don't understand this.  Nested functions must be nested in the sense that they have static chain information provided by gcc.

> Optimization should be allowed to inhibit debugging as much as it does for any other language.

What do you mean by this?

> 
> 
> I realize the type information getting around is probably a lot of work.
> And it is needed in m3back also, and probably not shared work.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Subject: m3cc static chain stuff
>> Date: Wed, 26 May 2010 06:05:25 +0000
>> 
>> 
>> Can any of this be removed?
>> Can we really not just use "unfold-nested-procs" like NT386?
>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>> generally a considered the responsibility of optimizers.
>> 
>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>> Maybe I'll try without.
>> 
>> 
>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
>> 
>> 
>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>> -   shared between INFO->CONTEXT and its nested functions.  This record will
>> -   not be complete until finalize_nesting_tree; up until that point we'll
>> +/* This must agree with the string defined by the same name in m3gdb, file
>> +   m3-util.c */
>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>> +
>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>> +   that is shared between INFO->CONTEXT and its nested functions.  This record
>> +   will not be complete until finalize_nesting_tree; up until that point we'll
>>    be adding fields as necessary.
>> 
>>    We also build the DECL that represents this frame in the function.  */
>> @@ -209,7 +224,8 @@
>>       free (name);
>> 
>>       info->frame_type = type;
>> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>> +      info->frame_decl
>> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>> 
>>       /* ??? Always make it addressable for now, since it is meant to
>>      be pointed to by the static chain pointer.  This pessimizes
>> @@ -218,6 +234,8 @@
>>      reachable, but the true pessimization is to create the non-
>>      local frame structure in the first place.  */
>>       TREE_ADDRESSABLE (info->frame_decl) = 1;
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (info->frame_decl) = 0;
>>     }
>>   return type;
>> }
>> @@ -290,6 +308,10 @@
>>   return *slot;
>> }
>> 
>> +/* This must agree with the string defined by the same name in m3gdb, file
>> +   m3_util.c */
>> +static const char * static_link_var_name = "_static_link_var";
>> +
>> /* Build or return the variable that holds the static chain within
>>    INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>> 
>> @@ -310,9 +332,14 @@
>>      Note also that it's represented as a parameter.  This is more
>>      close to the truth, since the initial value does come from
>>      the caller.  */
>> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>> +      decl = build_decl
>> +               (PARM_DECL, get_identifier (static_link_var_name), type);
>> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>       DECL_ARTIFICIAL (decl) = 1;
>> -      DECL_IGNORED_P (decl) = 1;
>> +
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (decl) = 0;
>> +
>>       TREE_USED (decl) = 1;
>>       DECL_CONTEXT (decl) = info->context;
>>       DECL_ARG_TYPE (decl) = type;
>> @@ -326,7 +353,11 @@
>>   return decl;
>> }
>> 
>> -/* Build or return the field within the non-local frame state that holds
>> +/* This must agree with the string defined by the same name in m3gdb, file
>> +   m3_util.c */
>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>> +
>> +/* Build or return the field within the non-local frame struct that holds
>>    the static chain for INFO->CONTEXT.  This is the way to walk back up
>>    multiple nesting levels.  */
>> 
>> @@ -339,10 +370,12 @@
>>       tree type = build_pointer_type (get_frame_type (info->outer));
>> 
>>       field = make_node (FIELD_DECL);
>> -      DECL_NAME (field) = get_identifier ("__chain");
>> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>       TREE_TYPE (field) = type;
>>       DECL_ALIGN (field) = TYPE_ALIGN (type);
>>       DECL_NONADDRESSABLE_P (field) = 1;
>> +      /* m3gdb should know about this field. */
>> +      DECL_IGNORED_P (field) = 0;
>> 
>>       insert_field_into_struct (get_frame_type (info), field);
>> 
>> @@ -465,7 +498,7 @@
>>   return *slot;
>> }
>> 
>> -/* Build or return the field within the non-local frame state that holds
>> +/* Build or return the field within the non-local frame struct that holds
>>    the non-local goto "jmp_buf".  The buffer itself is maintained by the
>>    rtl middle-end as dynamic stack space is allocated.  */
>> 
>> @@ -1620,6 +1653,9 @@
>>   switch (TREE_CODE (t))
>>     {
>>     case ADDR_EXPR:
>> +      if (TREE_STATIC (t))
>> +    break;
>> +
>>       /* Build
>>        T.1 = &CHAIN->tramp;
>>        T.2 = __builtin_adjust_trampoline (T.1);
>> @@ -1714,6 +1750,22 @@
>>     }
>>       break;
>> 
>> +    case STATIC_CHAIN_EXPR:
>> +      decl = TREE_OPERAND (t, 0);
>> +      target_context = decl_function_context (decl);
>> +      if (target_context)
>> +    {
>> +      if (info->context == target_context)
>> +        {
>> +          /* Make sure frame_decl gets created.  */
>> +          (void) get_frame_type (info);
>> +        }
>> +      *tp = get_static_chain (info, target_context, &wi->tsi);
>> +    }
>> +      else
>> +    *tp = null_pointer_node;
>> +      break;
>> +
>>     case RETURN_EXPR:
>>     case GIMPLE_MODIFY_STMT:
>>     case WITH_SIZE_EXPR:
>> @@ -1768,13 +1820,22 @@
>>   return NULL_TREE;
>> }
>> 
>> +static bool
>> +debug_static_links (void)
>> +{ return
>> +    write_symbols != NO_DEBUG
>> +    && debug_info_level != DINFO_LEVEL_NONE
>> +    && debug_info_level != DINFO_LEVEL_TERSE;
>> +
>> +} /* debug_static_links */
>> +
>> /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>>    trampolines and call expressions.  On the way back up, determine if
>>    a nested function actually uses its static chain; if not, remember that.  */
>> 
>> static void
>> convert_all_function_calls (struct nesting_info *root)
>> -{
>> +{
>>   do
>>     {
>>       if (root->inner)
>> @@ -1784,7 +1845,10 @@
>>       walk_function (convert_call_expr, root);
>> 
>>       /* If the function does not use a static chain, then remember that.  */
>> -      if (root->outer && !root->chain_decl && !root->chain_field)
>> +      if (root->outer && !root->chain_decl && !root->chain_field
>> +/* REMOVE ME: */
>> +          /* && !debug_static_links () */
>> +         )
>>     DECL_NO_STATIC_CHAIN (root->context) = 1;
>>       else
>>     gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>> @@ -1806,6 +1870,21 @@
>>   tree context = root->context;
>>   struct function *sf;
>> 
>> +/* REMOVEME: */
>> +  /* If this is a nested function and we are supporting debugging via
>> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
>> +     chain, even if the programmer's code doesn't use it. */
>> +  if (false && root->outer && debug_static_links () )
>> +    { tree static_chain_decl, temp, stmt;
>> +      /* This is a desperate attempt to get later code generation to
>> +         store the static link.  If it works, it'll be a miracle. */
>> +      static_chain_decl = get_chain_decl (root);
>> +      stmt = build_addr (static_chain_decl, root->context);
>> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>> +      append_to_statement_list (stmt, &stmt_list);
>> +    }
>> +
>>   /* If we created a non-local frame type or decl, we need to lay them
>>      out at this time.  */
>>   if (root->frame_type)
>> @@ -1912,7 +1991,7 @@
>>      proper BIND_EXPR.  */
>>   if (root->new_local_var_chain)
>>     declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>> -          false);
>> +          true);
>>   if (root->debug_var_chain)
>>     declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>           true);
>> 
>> 
>> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed May 26 16:28:51 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 26 May 2010 10:28:51 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
Message-ID: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>

We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible.  The only thing is that we also build closures, so the trampoline mechanisms should be avoided.


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 26 May 2010, at 02:05, Jay K wrote:

> 
> Can any of this be removed?
> Can we really not just use "unfold-nested-procs" like NT386?
> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
> generally a considered the responsibility of optimizers.
> 
> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
> Maybe I'll try without.
> 
> 
> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
> 
> 
> -/* Build or return the RECORD_TYPE that describes the frame state that is
> -   shared between INFO->CONTEXT and its nested functions.  This record will
> -   not be complete until finalize_nesting_tree; up until that point we'll
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3-util.c */ 
> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec"; 
> +
> +/* Build or return the RECORD_TYPE that describes the non-local frame struct 
> +   that is shared between INFO->CONTEXT and its nested functions.  This record 
> +   will not be complete until finalize_nesting_tree; up until that point we'll
>     be adding fields as necessary.
>  
>     We also build the DECL that represents this frame in the function.  */
> @@ -209,7 +224,8 @@
>        free (name);
>  
>        info->frame_type = type;
> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
> +      info->frame_decl 
> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>  
>        /* ??? Always make it addressable for now, since it is meant to
>       be pointed to by the static chain pointer.  This pessimizes
> @@ -218,6 +234,8 @@
>       reachable, but the true pessimization is to create the non-
>       local frame structure in the first place.  */
>        TREE_ADDRESSABLE (info->frame_decl) = 1;
> +      /* m3gdb needs to know about this variable. */ 
> +      DECL_IGNORED_P (info->frame_decl) = 0;  
>      }
>    return type;
>  }
> @@ -290,6 +308,10 @@
>    return *slot;
>  }
>  
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */ 
> +static const char * static_link_var_name = "_static_link_var"; 
> +
>  /* Build or return the variable that holds the static chain within
>     INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>  
> @@ -310,9 +332,14 @@
>       Note also that it's represented as a parameter.  This is more
>       close to the truth, since the initial value does come from 
>       the caller.  */
> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
> +      decl = build_decl 
> +               (PARM_DECL, get_identifier (static_link_var_name), type);
> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */ 
>        DECL_ARTIFICIAL (decl) = 1;
> -      DECL_IGNORED_P (decl) = 1;
> +
> +      /* m3gdb needs to know about this variable. */ 
> +      DECL_IGNORED_P (decl) = 0;
> +
>        TREE_USED (decl) = 1;
>        DECL_CONTEXT (decl) = info->context;
>        DECL_ARG_TYPE (decl) = type;
> @@ -326,7 +353,11 @@
>    return decl;
>  }
>  
> -/* Build or return the field within the non-local frame state that holds
> +/* This must agree with the string defined by the same name in m3gdb, file
> +   m3_util.c */ 
> +static const char * static_link_copy_field_name = "_static_link_copy_field"; 
> +
> +/* Build or return the field within the non-local frame struct that holds
>     the static chain for INFO->CONTEXT.  This is the way to walk back up
>     multiple nesting levels.  */
>  
> @@ -339,10 +370,12 @@
>        tree type = build_pointer_type (get_frame_type (info->outer));
>  
>        field = make_node (FIELD_DECL);
> -      DECL_NAME (field) = get_identifier ("__chain");
> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>        TREE_TYPE (field) = type;
>        DECL_ALIGN (field) = TYPE_ALIGN (type);
>        DECL_NONADDRESSABLE_P (field) = 1;
> +      /* m3gdb should know about this field. */ 
> +      DECL_IGNORED_P (field) = 0;  
>  
>        insert_field_into_struct (get_frame_type (info), field);
>  
> @@ -465,7 +498,7 @@
>    return *slot;
>  } 
>  
> -/* Build or return the field within the non-local frame state that holds
> +/* Build or return the field within the non-local frame struct that holds
>     the non-local goto "jmp_buf".  The buffer itself is maintained by the
>     rtl middle-end as dynamic stack space is allocated.  */
>  
> @@ -1620,6 +1653,9 @@
>    switch (TREE_CODE (t))
>      {
>      case ADDR_EXPR:
> +      if (TREE_STATIC (t))
> +    break;
> +
>        /* Build
>         T.1 = &CHAIN->tramp;
>         T.2 = __builtin_adjust_trampoline (T.1);
> @@ -1714,6 +1750,22 @@
>      }
>        break;
>  
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
>      case RETURN_EXPR:
>      case GIMPLE_MODIFY_STMT:
>      case WITH_SIZE_EXPR:
> @@ -1768,13 +1820,22 @@
>    return NULL_TREE;
>  }
>  
> +static bool
> +debug_static_links (void) 
> +{ return
> +    write_symbols != NO_DEBUG
> +    && debug_info_level != DINFO_LEVEL_NONE
> +    && debug_info_level != DINFO_LEVEL_TERSE;
> +
> +} /* debug_static_links */ 
> +
>  /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>     trampolines and call expressions.  On the way back up, determine if
>     a nested function actually uses its static chain; if not, remember that.  */
>  
>  static void
>  convert_all_function_calls (struct nesting_info *root)
> -{
> +{ 
>    do
>      {
>        if (root->inner)
> @@ -1784,7 +1845,10 @@
>        walk_function (convert_call_expr, root);
>  
>        /* If the function does not use a static chain, then remember that.  */
> -      if (root->outer && !root->chain_decl && !root->chain_field)
> +      if (root->outer && !root->chain_decl && !root->chain_field
> +/* REMOVE ME: */ 
> +          /* && !debug_static_links () */ 
> +         )
>      DECL_NO_STATIC_CHAIN (root->context) = 1;
>        else
>      gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
> @@ -1806,6 +1870,21 @@
>    tree context = root->context;
>    struct function *sf;
>  
> +/* REMOVEME: */ 
> +  /* If this is a nested function and we are supporting debugging via
> +     m3gdb, we always need a chain_decl, so m3gdb can find the static 
> +     chain, even if the programmer's code doesn't use it. */ 
> +  if (false && root->outer && debug_static_links () )
> +    { tree static_chain_decl, temp, stmt;
> +      /* This is a desperate attempt to get later code generation to 
> +         store the static link.  If it works, it'll be a miracle. */ 
> +      static_chain_decl = get_chain_decl (root); 
> +      stmt = build_addr (static_chain_decl, root->context); 
> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
> +      append_to_statement_list (stmt, &stmt_list);
> +    } 
> +
>    /* If we created a non-local frame type or decl, we need to lay them
>       out at this time.  */
>    if (root->frame_type)
> @@ -1912,7 +1991,7 @@
>       proper BIND_EXPR.  */
>    if (root->new_local_var_chain)
>      declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
> -          false);
> +          true);
>    if (root->debug_var_chain)
>      declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>            true);
> 
> 
> 		 	   		  

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

From jay.krell at cornell.edu  Wed May 26 17:02:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 15:02:10 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
Message-ID: <COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>


> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 10:28:51 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
>
>
> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.


Right..for those that don't know..


There's no "good" efficient way to implement nested functions.
Our implementation is pretty "bad".
gcc's implementation is pretty "bad".
They are different.


gcc (Tony mentions "trampoline"):
In particular, taking the address of a nested function
involves runtime code generation on the stack.
These days, running code on the stack is "difficult".
On some systems, you do mprotect() to make that part of the stack executable.
On other systems, you just can't do it (iPhone).
On older systems, no problem. It is simple and efficient.


Modula-3:
Whenever we go to call a function pointer, we first see if it start with a 4 or 8 byte -1.
If so, it is our "closure" thingy, and the -1 is followed
I guess by an actual function pointer and a static link.
The static link is loaded wherever and the function called.


Other systems (see modern ATL on Windows) allocate executable
memory not on the stack. Not even regular heap is executable
generally any longer though, one need to VirtualAlloc or mmap or such.


This is a powerful mechanism in general, you can do stuff like
runtime "currying".


Pointers to nested Modula-3 function cannot be passed off
as function pointers to other languages.
? But hey, at least we can write nested functions and pass
??? them off to ourselves. Interop with C would just be bonus?


Calling function pointers in Modula-3 is slowed down
everywhere, in case the function pointer is nested.
I think.


-1 must be ensured to be invalid code.
Or we could make it a more visible part of porting.
?You know -- it could be per-target and folks would have
?to experiment with each target to find a good sequence,
?that is cheap to detect and guaranteed invalid.
?(ie: 0 might be better than -1!)


Could possibly replace the -1 with an actual function pointer
that is always called.
But then pointers to non-nested functions also wouldn't
interoperate with C.


I think there's something more to the mechanisms than I realize.
The "static link" must survive calls out to non-nested functions
or somesuch.


Anyway, while I think our mechanism is pretty clearly flawed,
it seems to be slightly less bad than gcc's.


Perhaps we should invest in what ATL does though and
dynamically allocate executable memory not on the stack?
Still, an "open" iPhone is probably better with the current scheme.
Most other systems should be ok either way.


I think there is a bit of 4.3=>4.5 that needs closer attention
and isn't obvious, this part:

+??? case STATIC_CHAIN_EXPR:
+????? decl = TREE_OPERAND (t, 0);
+????? target_context = decl_function_context (decl);
+????? if (target_context)
+??? {
+??? ? if (info->context == target_context)
+??? ??? {
+??? ????? /* Make sure frame_decl gets created.? */
+??? ????? (void) get_frame_type (info);
+??? ??? }
+??? ? *tp = get_static_chain (info, target_context, &wi->tsi);
+??? }
+????? else
+??? *tp = null_pointer_node;
+????? break;
+

?- Jay
 		 	   		  

From jay.krell at cornell.edu  Wed May 26 17:13:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 15:13:38 +0000
Subject: [M3devel] closure marker
Message-ID: <COL101-W251CA496DF1BD58A8AEB48E6E90@phx.gbl>


As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
64bit systems that care about alignment pay quite a penality imho.


I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.


If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.


I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
? Do they have 4 byte instructions, that are always 4 byte aligned?


IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.


More general might be
? Target.ClosureElementSize? (bits)
? Target.ClosureElementCount? 


IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
Whereas most others would have Target.ClosureElementSize? = 32, Target.ClosureElementSize? = 1.
ClosureElementSize would be chosen to be match guaranteed code alignment.



? - Jay

 		 	   		  

From jay.krell at cornell.edu  Wed May 26 18:45:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 16:45:06 +0000
Subject: [M3devel] closure marker
Message-ID: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>


A little bit of research done (just searching the web):
?Mips, Alpha, PowerPC, HPPA, ARM, SPARC


all appear to use a 32bit instruction
presumably aligned but I couldn't confirm for all of them.
? It seems likely that if the processor cares about data alignment, then code will be aligned the same.


Looks like SH has 16bit instructions.


I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
With IA64 the expected exception with size=64bits, count=2.
? It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
? We can revisit at that time.
And really size=64, count=1 might suffice.

I'm a little torn.
A 64bit marker is more certain.
Code has been this way forever.
etc.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Subject: closure marker
> Date: Wed, 26 May 2010 15:13:38 +0000
>
>
> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
> 64bit systems that care about alignment pay quite a penality imho.
>
>
> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>
>
> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>
>
> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>   Do they have 4 byte instructions, that are always 4 byte aligned?
>
>
> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>
>
> More general might be
>   Target.ClosureElementSize  (bits)
>   Target.ClosureElementCount
>
>
> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
> Whereas most others would have Target.ClosureElementSize  = 32, Target.ClosureElementSize  = 1.
> ClosureElementSize would be chosen to be match guaranteed code alignment.
>
>
>
>   - Jay
>
>
 		 	   		  

From hendrik at topoi.pooq.com  Wed May 26 15:25:25 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Wed, 26 May 2010 09:25:25 -0400
Subject: [M3devel] OS for CM3
In-Reply-To: <729398.10895.qm@web23605.mail.ird.yahoo.com>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
	<729398.10895.qm@web23605.mail.ird.yahoo.com>
Message-ID: <20100526132524.GB18812@topoi.pooq.com>

On Tue, May 25, 2010 at 04:07:24AM +0000, Daniel Alejandro Benavides D. wrote:
> Hi:
> if easy of administration is what you are looking for maybe a bsd 
> flavour a is the right choice of use probably it would be a linux 
> distro but a common sense of easy administration and use like ubuntu 
> rh/centos server or why not a gentoo or archlinux if customization is 
> what you want to add more cores linux will support up to 1024 and the 
> small or medium size servers are commonly used in this servers sizes I 
> guess you have a good choice to take advantage, how many does support 
> Win server 2k3 (up to 64?) an another bsd up to how many?  
> 
> Hope it helps, thanks in advance

The next release of Debian is supposed to run on a BSD kernel as one of 
its platforms.  So there will be Linux and nonLinux distros for Debian.

-- hendrik


From hosking at cs.purdue.edu  Wed May 26 22:13:29 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 26 May 2010 16:13:29 -0400
Subject: [M3devel] DECL_LANG_SPECIFIC and casts?
In-Reply-To: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>
References: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>
Message-ID: <8EDE1A93-0507-43C2-8DF4-9291B1C4C8E4@cs.purdue.edu>

Why would this be problematic?  We need to retain it for later use, and I remember making sure that this worked.  Does the collector somehow delete the target?

On 26 May 2010, at 10:20, Jay K wrote:

> 
> Tony, this thing where we do:
> 
>   DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
> ...
> 
>       tree var = (tree)DECL_LANG_SPECIFIC(index);
> 
> 
> Is this running afoul of the gcc garbage collector?
>   Seems likely.
> 
> And does it matter?
>   Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
>  assuming m3_write_globals is called near the end.
> 
> 
> Thing is:
> struct lang_identifier GTY(()) ...
> union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
> struct lang_type GTY(()) ...
> typedef struct lang_decl GTY(()) ...
> struct language_function GTY(()) ...
> 
> 
> Which are nearly unused, cause me grief.
> They have to be different for 4.5 vs. 4.2/4.3.
>   Just the GTY needs to be moved to before the union/struct tag.
> 
> 
> I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
>   I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
>    aren't so small like ours so I'd rather not.
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Wed May 26 23:54:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 21:54:45 +0000
Subject: [M3devel] DECL_LANG_SPECIFIC and casts?
In-Reply-To: <8EDE1A93-0507-43C2-8DF4-9291B1C4C8E4@cs.purdue.edu>
References: <COL101-W1577B00B87120425C5FF81E6E90@phx.gbl>,
	<8EDE1A93-0507-43C2-8DF4-9291B1C4C8E4@cs.purdue.edu>
Message-ID: <COL101-W43FC8D66C4B28F3CEC856AE6E90@phx.gbl>


Nevermind.
In 4.3 you have to say
struct foo GTY(())

in 4.5 you have to say struct GTY foo(());

Just on the type/field declarations.
Variables have the same syntax.

I asssume 4.2 matches 4.3 but I have to double check.

Apple, therefore iPhone, is still on 4.2.
I don't want to merge.
I'd rather keep 4.2/4.5 compatible code.

So if possible, would like to remove this stuff.
But doesn't seem possible.
Instead I'll move it to 4.2/4.5-specific files.

Unless by chance 4.2 is ok with the 4.5 form. 4.3 isn't.
Unfortunate.

? - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 16:13:29 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] DECL_LANG_SPECIFIC and casts?
>
> Why would this be problematic? We need to retain it for later use, and I remember making sure that this worked. Does the collector somehow delete the target?
>
> On 26 May 2010, at 10:20, Jay K wrote:
>
>>
>> Tony, this thing where we do:
>>
>> DECL_LANG_SPECIFIC(f) = (lang_decl_t*)var; /* we will fix the offset later once we have rtl */
>> ...
>>
>> tree var = (tree)DECL_LANG_SPECIFIC(index);
>>
>>
>> Is this running afoul of the gcc garbage collector?
>> Seems likely.
>>
>> And does it matter?
>> Seems very uncertain. I know almost nothing here, but it looks like we do hold on to the thing until the end anyway,
>> assuming m3_write_globals is called near the end.
>>
>>
>> Thing is:
>> struct lang_identifier GTY(()) ...
>> union lang_tree_node GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"))) ...
>> struct lang_type GTY(()) ...
>> typedef struct lang_decl GTY(()) ...
>> struct language_function GTY(()) ...
>>
>>
>> Which are nearly unused, cause me grief.
>> They have to be different for 4.5 vs. 4.2/4.3.
>> Just the GTY needs to be moved to before the union/struct tag.
>>
>>
>> I'd like to keep the code compatible with 4.2 at least until a separate upgrade of the iPhone backend.
>> I haven't checked what Apple is up to there though. Could also make sense to merge their changes..but there's generally
>> aren't so small like ours so I'd rather not.
>>
>>
>> - Jay
>>
>
 		 	   		  

From rodney_bates at lcwb.coop  Thu May 27 00:37:07 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 17:37:07 -0500
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>
Message-ID: <4BFDA293.9080503@lcwb.coop>

I left it in because it is a work in progress.  I *really* want to get it to
work, and I don't what to have to reinvent what is already there when I get
to it.  I use nested procedures extensively in certain situations, and good
debugger support of them is important to me.  It all works fine on older code
generators than the gcc that added tree-nested.c.

Jay K wrote:
> Rodney, you added this function, along with a comment that says it doesn't actually work.
> Does it work?
> Does it accomplish anything?
> Can I remove it and its calls?
> 
> /* Special-purpose function to write stabs for the static_chain_decl. 
>    So far, this is not working.  m3gdb needs the place in the activation
>    record where the SL is stored.  Right now, the SL is not necessarily
>    stored at all, but may just be kept in a register.  DECL_RTL and 
>    DECL_INCOMING_RTL may both have register expressions.  But stabs
>    entries for register variables, of kind N_RSYM, are currently ignored
>    by gdb in dbxread.c, and making it read them could create problems
>    elsewhere, because there can be other variables for which both an
>    N_RSYM and an N_LSYM stabs entry are created.   
> */ 
> static int 
> dbxout_static_chain_decl (tree decl) 
> 
> It was added 19 months ago by:
>   http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
> 
> as well, do we need the #if 0 code added then?
> 
>  - Jay
>  		 	   		  


From jay.krell at cornell.edu  Thu May 27 00:53:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 22:53:24 +0000
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <4BFDA293.9080503@lcwb.coop>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>,
	<4BFDA293.9080503@lcwb.coop>
Message-ID: <COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>


Rodney, When you get back to it, can you just dig it out of history?
 
 
I still think we should try to avoid gcc's nested function functionality.
 
 
Where you use the static chain, not using the nested function functionality should
"automatically" be debuggable -- "automatic" as in, once the work is done
in the frontend to transform out nesting.
 
 
"debuggable" as in, you could follow the links yourself in the debugger.
The debugger need not search lexically nested functions that have function
calls dividing them.
 
 
?
 
 
There's stuff I still need to understand better -- particularly the affect of nested functions
on non-nested functions. Is there *always* an extra parameter to *all* functions?
It appears so.
And I haven't figured out how to merge with 4.5 what I think achieves that.
 
 
Maybe a good test of test cases here?
 
 
 
 - Jay


----------------------------------------
> Date: Wed, 26 May 2010 17:37:07 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
> I left it in because it is a work in progress. I *really* want to get it to
> work, and I don't what to have to reinvent what is already there when I get
> to it. I use nested procedures extensively in certain situations, and good
> debugger support of them is important to me. It all works fine on older code
> generators than the gcc that added tree-nested.c.
>
> Jay K wrote:
>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>> Does it work?
>> Does it accomplish anything?
>> Can I remove it and its calls?
>>
>> /* Special-purpose function to write stabs for the static_chain_decl.
>> So far, this is not working. m3gdb needs the place in the activation
>> record where the SL is stored. Right now, the SL is not necessarily
>> stored at all, but may just be kept in a register. DECL_RTL and
>> DECL_INCOMING_RTL may both have register expressions. But stabs
>> entries for register variables, of kind N_RSYM, are currently ignored
>> by gdb in dbxread.c, and making it read them could create problems
>> elsewhere, because there can be other variables for which both an
>> N_RSYM and an N_LSYM stabs entry are created.
>> */
>> static int
>> dbxout_static_chain_decl (tree decl)
>>
>> It was added 19 months ago by:
>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>
>> as well, do we need the #if 0 code added then?
>>
>> - Jay
>> 		 	   		  

From rodney_bates at lcwb.coop  Thu May 27 01:04:42 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 18:04:42 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>
Message-ID: <4BFDA90A.3050105@lcwb.coop>



Jay K wrote:
>> From: hosking at cs.purdue.edu
>> Date: Wed, 26 May 2010 10:28:51 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>>
>>
>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, 

whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
> 
> 
> Right..for those that don't know..
> 
> 
> There's no "good" efficient way to implement nested functions.
> Our implementation is pretty "bad".
> gcc's implementation is pretty "bad".

I think this is far too critical.  The inefficiencies you see are
minor.  Certainly no worse than the implementation of dispatching
methods of objects, something the world is gaga about.  And the
inefficiencies I think you are worrying about only arise when
you pass procedures as parameters.




> They are different.
> 
> 
> gcc (Tony mentions "trampoline"):
> In particular, taking the address of a nested function
> involves runtime code generation on the stack.
> These days, running code on the stack is "difficult".
> On some systems, you do mprotect() to make that part of the stack executable.
> On other systems, you just can't do it (iPhone).
> On older systems, no problem. It is simple and efficient.
> 

Yes, that is one consequence of trampolines.  There has to be a place
to generate code at runtime that will be executable, and a way to
memory-manage it.

> 
> Modula-3:
> Whenever we go to call a function pointer, we first see if it start with a 4 or 8 byte -1.
> If so, it is our "closure" thingy, and the -1 is followed
> I guess by an actual function pointer and a static link.
> The static link is loaded wherever and the function called.
> 
> 
> Other systems (see modern ATL on Windows) allocate executable
> memory not on the stack. Not even regular heap is executable
> generally any longer though, one need to VirtualAlloc or mmap or such.
> 
> 
> This is a powerful mechanism in general, you can do stuff like
> runtime "currying".
> 
> 
> Pointers to nested Modula-3 function cannot be passed off
> as function pointers to other languages.
>   But hey, at least we can write nested functions and pass
>     them off to ourselves. Interop with C would just be bonus?
> 

But if we used trampolines instead of our form of closures, they
could be.  Or, more generally, if we used the same mechanism as
"other languages", they could be.

> 
> Calling function pointers in Modula-3 is slowed down
> everywhere, in case the function pointer is nested.
> I think.

Only calling procedures through a procedure-typed _parameter_ is
slowed down.  Calling through a procedure-typed _variable_ is known,
by language semantics, always to be to a top-level procedure, and
is as fast as a C call to a non-nested function pointer.
Note that, when calling a function pointer to a nested procedure,
trampolines are surely about as fast as you can get.

> 
> 
> -1 must be ensured to be invalid code.
> Or we could make it a more visible part of porting.
>  You know -- it could be per-target and folks would have
>  to experiment with each target to find a good sequence,
>  that is cheap to detect and guaranteed invalid.
>  (ie: 0 might be better than -1!)
> 
> 
> Could possibly replace the -1 with an actual function pointer
> that is always called.
> But then pointers to non-nested functions also wouldn't
> interoperate with C.

I don't understand what mechanism you are proposing here.  Taken
literally, it sounds like a trampoline to me, which would allow
non-nested and nested function pointers to interoperate with C.

> 
> 
> I think there's something more to the mechanisms than I realize.
> The "static link" must survive calls out to non-nested functions
> or somesuch.
> 
> 
> Anyway, while I think our mechanism is pretty clearly flawed,
> it seems to be slightly less bad than gcc's.
> 

I'm not sure what you mean by flawed, but if you mean it doesn't
correctly implement language semantics, that is not true.  It works
correctly.  So do trampolines, although in C (for other reasons that
are independent of what mechanism you use for function pointers),
the semantics of the language have a big hole.  As usual, C passes
the buck by defining this as "undefined".

> 
> Perhaps we should invest in what ATL does though and
> dynamically allocate executable memory not on the stack?

If there is a way to do this, then trampolines can be made to work.
What does gcc do now on such targets?

> Still, an "open" iPhone is probably better with the current scheme.
> Most other systems should be ok either way.
> 
> 
> I think there is a bit of 4.3=>4.5 that needs closer attention
> and isn't obvious, this part:
> 
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
> 
>  - Jay
>  

Jay, you have made it clear repeatedly that you only use gdb, and
never m3gdb, so obviously, Modula-3-specific support is of no importance
to you.  That's OK, but please don't spoil the game for those of us
who do care about it by ripping stuff out of the compiler that m3gdb
needs.  Even when it isn't fully working yet.

		 	   		


From jay.krell at cornell.edu  Thu May 27 00:56:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 22:56:19 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>
References: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>,
	<88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>
Message-ID: <COL101-W50960886C3E99F184DBA1CE6E90@phx.gbl>


>> Nested functions should be transformed to not be nested. Imho.
 
> I don't understand this. Nested functions must be nested in the sense that
> they have static chain information provided by gcc.
 
 
 
Can it be achieved by adding an extra parameter instead?
 
 
 
>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
> What do you mean by this?
 
 
 
It looks like we inhibit optimization if -g is specified.
Like we preserve unused static chains.
This is has been discussed and I have to look at the code more..
Generating debug information should not inhibit optimization.
 
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 26 May 2010 10:26:32 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
> On 26 May 2010, at 03:55, Jay K wrote:
>
>>
>> I'm going to try to keep the code that seems to do anything, however:
>>
>> 1) if (false &&
>>
>> I plan to remove that.
>>
>>
>> 2)
>> + if (root->outer && !root->chain_decl && !root->chain_field
>> +/* REMOVE ME: */
>> + /* && !debug_static_links () */
>> + )
>>
>>
>> I can't find where that would apply, and it is commented out anyway so I'll remove it.
>>
>>
>> I'm open to arguments though. :)
>>
>> dbxout.c
>> +#if 0
>> +/* Code copied from 1.4.2.2: */
>>
>>
>> I can cheaply enough keep that...should we really though?
>>
>>
>> I really think we can reduce our changes.
>> Enough type information should be passed around so that regular gdb works. Imho.
>
> Possibly, but M3 has a very different notion of type to C. Moreover, it is extremely valuable to have the M3 type ids there so that functionality can map back to the types in the M3 runtime system. It would be possible to implement much of the m3gdb debugging support by calling back into the language run-time passing the language type ids instead of relying on hand-crafted C in m3gdb. But I agree that more type information would be good, particularly for records.
>
>> And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
>> don't cause internal compiler errors. So that debug info might be generated on systems
>> that don't support stabs though granted they are few and minor (hppa64-hpux).
>> Nested functions should be transformed to not be nested. Imho.
>
> I don't understand this. Nested functions must be nested in the sense that they have static chain information provided by gcc.
>
>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
>
> What do you mean by this?
>
>>
>>
>> I realize the type information getting around is probably a lot of work.
>> And it is needed in m3back also, and probably not shared work.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: m3cc static chain stuff
>>> Date: Wed, 26 May 2010 06:05:25 +0000
>>>
>>>
>>> Can any of this be removed?
>>> Can we really not just use "unfold-nested-procs" like NT386?
>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>> generally a considered the responsibility of optimizers.
>>>
>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>> Maybe I'll try without.
>>>
>>>
>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>
>>>
>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> + m3-util.c */
>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>> +
>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>> be adding fields as necessary.
>>>
>>> We also build the DECL that represents this frame in the function. */
>>> @@ -209,7 +224,8 @@
>>> free (name);
>>>
>>> info->frame_type = type;
>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>> + info->frame_decl
>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>
>>> /* ??? Always make it addressable for now, since it is meant to
>>> be pointed to by the static chain pointer. This pessimizes
>>> @@ -218,6 +234,8 @@
>>> reachable, but the true pessimization is to create the non-
>>> local frame structure in the first place. */
>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>> + /* m3gdb needs to know about this variable. */
>>> + DECL_IGNORED_P (info->frame_decl) = 0;
>>> }
>>> return type;
>>> }
>>> @@ -290,6 +308,10 @@
>>> return *slot;
>>> }
>>>
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> + m3_util.c */
>>> +static const char * static_link_var_name = "_static_link_var";
>>> +
>>> /* Build or return the variable that holds the static chain within
>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>
>>> @@ -310,9 +332,14 @@
>>> Note also that it's represented as a parameter. This is more
>>> close to the truth, since the initial value does come from
>>> the caller. */
>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>> + decl = build_decl
>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>> DECL_ARTIFICIAL (decl) = 1;
>>> - DECL_IGNORED_P (decl) = 1;
>>> +
>>> + /* m3gdb needs to know about this variable. */
>>> + DECL_IGNORED_P (decl) = 0;
>>> +
>>> TREE_USED (decl) = 1;
>>> DECL_CONTEXT (decl) = info->context;
>>> DECL_ARG_TYPE (decl) = type;
>>> @@ -326,7 +353,11 @@
>>> return decl;
>>> }
>>>
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> + m3_util.c */
>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>> +
>>> +/* Build or return the field within the non-local frame struct that holds
>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>> multiple nesting levels. */
>>>
>>> @@ -339,10 +370,12 @@
>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>
>>> field = make_node (FIELD_DECL);
>>> - DECL_NAME (field) = get_identifier ("__chain");
>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>> TREE_TYPE (field) = type;
>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>> DECL_NONADDRESSABLE_P (field) = 1;
>>> + /* m3gdb should know about this field. */
>>> + DECL_IGNORED_P (field) = 0;
>>>
>>> insert_field_into_struct (get_frame_type (info), field);
>>>
>>> @@ -465,7 +498,7 @@
>>> return *slot;
>>> }
>>>
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* Build or return the field within the non-local frame struct that holds
>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>> rtl middle-end as dynamic stack space is allocated. */
>>>
>>> @@ -1620,6 +1653,9 @@
>>> switch (TREE_CODE (t))
>>> {
>>> case ADDR_EXPR:
>>> + if (TREE_STATIC (t))
>>> + break;
>>> +
>>> /* Build
>>> T.1 = &CHAIN->tramp;
>>> T.2 = __builtin_adjust_trampoline (T.1);
>>> @@ -1714,6 +1750,22 @@
>>> }
>>> break;
>>>
>>> + case STATIC_CHAIN_EXPR:
>>> + decl = TREE_OPERAND (t, 0);
>>> + target_context = decl_function_context (decl);
>>> + if (target_context)
>>> + {
>>> + if (info->context == target_context)
>>> + {
>>> + /* Make sure frame_decl gets created. */
>>> + (void) get_frame_type (info);
>>> + }
>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>> + }
>>> + else
>>> + *tp = null_pointer_node;
>>> + break;
>>> +
>>> case RETURN_EXPR:
>>> case GIMPLE_MODIFY_STMT:
>>> case WITH_SIZE_EXPR:
>>> @@ -1768,13 +1820,22 @@
>>> return NULL_TREE;
>>> }
>>>
>>> +static bool
>>> +debug_static_links (void)
>>> +{ return
>>> + write_symbols != NO_DEBUG
>>> + && debug_info_level != DINFO_LEVEL_NONE
>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>> +
>>> +} /* debug_static_links */
>>> +
>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>> trampolines and call expressions. On the way back up, determine if
>>> a nested function actually uses its static chain; if not, remember that. */
>>>
>>> static void
>>> convert_all_function_calls (struct nesting_info *root)
>>> -{
>>> +{
>>> do
>>> {
>>> if (root->inner)
>>> @@ -1784,7 +1845,10 @@
>>> walk_function (convert_call_expr, root);
>>>
>>> /* If the function does not use a static chain, then remember that. */
>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>> +/* REMOVE ME: */
>>> + /* && !debug_static_links () */
>>> + )
>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>> else
>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>> @@ -1806,6 +1870,21 @@
>>> tree context = root->context;
>>> struct function *sf;
>>>
>>> +/* REMOVEME: */
>>> + /* If this is a nested function and we are supporting debugging via
>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>> + chain, even if the programmer's code doesn't use it. */
>>> + if (false && root->outer && debug_static_links () )
>>> + { tree static_chain_decl, temp, stmt;
>>> + /* This is a desperate attempt to get later code generation to
>>> + store the static link. If it works, it'll be a miracle. */
>>> + static_chain_decl = get_chain_decl (root);
>>> + stmt = build_addr (static_chain_decl, root->context);
>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>> + append_to_statement_list (stmt, &stmt_list);
>>> + }
>>> +
>>> /* If we created a non-local frame type or decl, we need to lay them
>>> out at this time. */
>>> if (root->frame_type)
>>> @@ -1912,7 +1991,7 @@
>>> proper BIND_EXPR. */
>>> if (root->new_local_var_chain)
>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>> - false);
>>> + true);
>>> if (root->debug_var_chain)
>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>> true);
>>>
>>>
>>>
>>
> 		 	   		  

From rodney_bates at lcwb.coop  Thu May 27 01:14:34 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 18:14:34 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
Message-ID: <4BFDAB5A.6000304@lcwb.coop>



Tony Hosking wrote:
> We should endeavour to use the same functionality that the C compiler 
> uses for its own nested functions, whereever possible.  The only thing 
> is that we also build closures, so the trampoline mechanisms should be 
> avoided.

I don't follow the last part of this argument.  If we follow the first
principle, we would just use trampolines, since they are the same
mechanism the C compiler uses.  And the only place they are not possible
are places where they won't work for C either (e.g., a target where there
is no place to construct code at runtime and have it be executable).
The mere fact that we "also build closures" is not a necessity, just
the reflection of the design decision to use the closure mechanism
instead of trampolines.

OTHO, despite all the positive things I have said here and in another post
about trampolines, I don't favor using them, because they would make m3gdb
support a lot more difficult.  m3gdb needs to be able to both read and
construct closures/trampolines, whichever.  Closures are almost target-
independent, except for the native word size, which is already easily
available to m3gdb.  Trampolines are going to be different for every
instruction set, and the ones constructed by compiled code, at least,
could even change with compiler version.  m3gdb would need a _lot_ of
highly target-dependent code to handle them.

> 
> 
> 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 26 May 2010, at 02:05, Jay K wrote:
> 
>>
>> Can any of this be removed?
>> Can we really not just use "unfold-nested-procs" like NT386?
>> We'd just lose a little bit of optimization, in rare cases, stop 
>> paying a bad cost/benefit ratio?
>> Part of this is actually *deoptimization*. If the compiler decides the 
>> values aren't used, then it should
>> be allowed to remove them. That is normal. Wanting to unused stuff in 
>> the debugger isn't
>> generally a considered the responsibility of optimizers.
>>
>> Therefore -- we could "unfold", remove our diffs, and gain some 
>> optimization and some deoptimization.
>> Maybe I'll try without.
>>
>>
>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c 
>> /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 
>> 09:36:43.000000000 -0800
>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 
>> 22:27:58.000000000 -0700
>>
>>
>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>> -   shared between INFO->CONTEXT and its nested functions.  This 
>> record will
>> -   not be complete until finalize_nesting_tree; up until that point we'll
>> +/* This must agree with the string defined by the same name in m3gdb, 
>> file
>> +   m3-util.c */
>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>> +
>> +/* Build or return the RECORD_TYPE that describes the non-local frame 
>> struct
>> +   that is shared between INFO->CONTEXT and its nested functions.  
>> This record
>> +   will not be complete until finalize_nesting_tree; up until that 
>> point we'll
>>     be adding fields as necessary.
>>  
>>     We also build the DECL that represents this frame in the function.  */
>> @@ -209,7 +224,8 @@
>>        free (name);
>>  
>>        info->frame_type = type;
>> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>> +      info->frame_decl
>> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>  
>>        /* ??? Always make it addressable for now, since it is meant to
>>       be pointed to by the static chain pointer.  This pessimizes
>> @@ -218,6 +234,8 @@
>>       reachable, but the true pessimization is to create the non-
>>       local frame structure in the first place.  */
>>        TREE_ADDRESSABLE (info->frame_decl) = 1;
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (info->frame_decl) = 0; 
>>      }
>>    return type;
>>  }
>> @@ -290,6 +308,10 @@
>>    return *slot;
>>  }
>>  
>> +/* This must agree with the string defined by the same name in m3gdb, 
>> file
>> +   m3_util.c */
>> +static const char * static_link_var_name = "_static_link_var";
>> +
>>  /* Build or return the variable that holds the static chain within
>>     INFO->CONTEXT.  This variable may only be used within 
>> INFO->CONTEXT.  */
>>  
>> @@ -310,9 +332,14 @@
>>       Note also that it's represented as a parameter.  This is more
>>       close to the truth, since the initial value does come from
>>       the caller.  */
>> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>> +      decl = build_decl
>> +               (PARM_DECL, get_identifier (static_link_var_name), type);
>> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout 
>> needs it. */
>>        DECL_ARTIFICIAL (decl) = 1;
>> -      DECL_IGNORED_P (decl) = 1;
>> +
>> +      /* m3gdb needs to know about this variable. */
>> +      DECL_IGNORED_P (decl) = 0;
>> +
>>        TREE_USED (decl) = 1;
>>        DECL_CONTEXT (decl) = info->context;
>>        DECL_ARG_TYPE (decl) = type;
>> @@ -326,7 +353,11 @@
>>    return decl;
>>  }
>>  
>> -/* Build or return the field within the non-local frame state that holds
>> +/* This must agree with the string defined by the same name in m3gdb, 
>> file
>> +   m3_util.c */
>> +static const char * static_link_copy_field_name = 
>> "_static_link_copy_field";
>> +
>> +/* Build or return the field within the non-local frame struct that holds
>>     the static chain for INFO->CONTEXT.  This is the way to walk back up
>>     multiple nesting levels.  */
>>  
>> @@ -339,10 +370,12 @@
>>        tree type = build_pointer_type (get_frame_type (info->outer));
>>  
>>        field = make_node (FIELD_DECL);
>> -      DECL_NAME (field) = get_identifier ("__chain");
>> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>        TREE_TYPE (field) = type;
>>        DECL_ALIGN (field) = TYPE_ALIGN (type);
>>        DECL_NONADDRESSABLE_P (field) = 1;
>> +      /* m3gdb should know about this field. */
>> +      DECL_IGNORED_P (field) = 0; 
>>  
>>        insert_field_into_struct (get_frame_type (info), field);
>>  
>> @@ -465,7 +498,7 @@
>>    return *slot;
>>  }
>>  
>> -/* Build or return the field within the non-local frame state that holds
>> +/* Build or return the field within the non-local frame struct that holds
>>     the non-local goto "jmp_buf".  The buffer itself is maintained by the
>>     rtl middle-end as dynamic stack space is allocated.  */
>>  
>> @@ -1620,6 +1653,9 @@
>>    switch (TREE_CODE (t))
>>      {
>>      case ADDR_EXPR:
>> +      if (TREE_STATIC (t))
>> +    break;
>> +
>>        /* Build
>>         T.1 = &CHAIN->tramp;
>>         T.2 = __builtin_adjust_trampoline (T.1);
>> @@ -1714,6 +1750,22 @@
>>      }
>>        break;
>>  
>> +    case STATIC_CHAIN_EXPR:
>> +      decl = TREE_OPERAND (t, 0);
>> +      target_context = decl_function_context (decl);
>> +      if (target_context)
>> +    {
>> +      if (info->context == target_context)
>> +        {
>> +          /* Make sure frame_decl gets created.  */
>> +          (void) get_frame_type (info);
>> +        }
>> +      *tp = get_static_chain (info, target_context, &wi->tsi);
>> +    }
>> +      else
>> +    *tp = null_pointer_node;
>> +      break;
>> +
>>      case RETURN_EXPR:
>>      case GIMPLE_MODIFY_STMT:
>>      case WITH_SIZE_EXPR:
>> @@ -1768,13 +1820,22 @@
>>    return NULL_TREE;
>>  }
>>  
>> +static bool
>> +debug_static_links (void)
>> +{ return
>> +    write_symbols != NO_DEBUG
>> +    && debug_info_level != DINFO_LEVEL_NONE
>> +    && debug_info_level != DINFO_LEVEL_TERSE;
>> +
>> +} /* debug_static_links */
>> +
>>  /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>>     trampolines and call expressions.  On the way back up, determine if
>>     a nested function actually uses its static chain; if not, remember 
>> that.  */
>>  
>>  static void
>>  convert_all_function_calls (struct nesting_info *root)
>> -{
>> +{
>>    do
>>      {
>>        if (root->inner)
>> @@ -1784,7 +1845,10 @@
>>        walk_function (convert_call_expr, root);
>>  
>>        /* If the function does not use a static chain, then remember 
>> that.  */
>> -      if (root->outer && !root->chain_decl && !root->chain_field)
>> +      if (root->outer && !root->chain_decl && !root->chain_field
>> +/* REMOVE ME: */
>> +          /* && !debug_static_links () */
>> +         )
>>      DECL_NO_STATIC_CHAIN (root->context) = 1;
>>        else
>>      gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>> @@ -1806,6 +1870,21 @@
>>    tree context = root->context;
>>    struct function *sf;
>>  
>> +/* REMOVEME: */
>> +  /* If this is a nested function and we are supporting debugging via
>> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
>> +     chain, even if the programmer's code doesn't use it. */
>> +  if (false && root->outer && debug_static_links () )
>> +    { tree static_chain_decl, temp, stmt;
>> +      /* This is a desperate attempt to get later code generation to
>> +         store the static link.  If it works, it'll be a miracle. */
>> +      static_chain_decl = get_chain_decl (root);
>> +      stmt = build_addr (static_chain_decl, root->context);
>> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), 
>> NULL);
>> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>> +      append_to_statement_list (stmt, &stmt_list);
>> +    }
>> +
>>    /* If we created a non-local frame type or decl, we need to lay them
>>       out at this time.  */
>>    if (root->frame_type)
>> @@ -1912,7 +1991,7 @@
>>       proper BIND_EXPR.  */
>>    if (root->new_local_var_chain)
>>      declare_vars (root->new_local_var_chain, DECL_SAVED_TREE 
>> (root->context),
>> -          false);
>> +          true);
>>    if (root->debug_var_chain)
>>      declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>            true);
>>
>>
>>     
> 


From rodney_bates at lcwb.coop  Thu May 27 01:20:38 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Wed, 26 May 2010 18:20:38 -0500
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>
Message-ID: <4BFDACC6.6020600@lcwb.coop>

After the marker, a closure also has two pointers, one to executable code,
and one to an environment of nonlocal variables.  These will always have
to be aligned to whatever pointers require on the target.  So making the
marker smaller than a native pointer would then require padding the
closure to get the pointers aligned.  This uses as much space as just
keeping the marker word-sized.

And no, I don't think it makes any sense to (on a 64-bit target) start
a closure on an odd multiple of 4 bytes, just so you can make the marker
smaller while keeping the following pointers word-aligned.

Jay K wrote:
> A little bit of research done (just searching the web):
>  Mips, Alpha, PowerPC, HPPA, ARM, SPARC
> 
> 
> all appear to use a 32bit instruction
> presumably aligned but I couldn't confirm for all of them.
>   It seems likely that if the processor cares about data alignment, then code will be aligned the same.
> 
> 
> Looks like SH has 16bit instructions.
> 
> 
> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
> With IA64 the expected exception with size=64bits, count=2.
>   It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>   We can revisit at that time.
> And really size=64, count=1 might suffice.
> 
> I'm a little torn.
> A 64bit marker is more certain.
> Code has been this way forever.
> etc.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>> Subject: closure marker
>> Date: Wed, 26 May 2010 15:13:38 +0000
>>
>>
>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>> 64bit systems that care about alignment pay quite a penality imho.
>>
>>
>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>
>>
>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>
>>
>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>   Do they have 4 byte instructions, that are always 4 byte aligned?
>>
>>
>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>
>>
>> More general might be
>>   Target.ClosureElementSize  (bits)
>>   Target.ClosureElementCount
>>
>>
>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>> Whereas most others would have Target.ClosureElementSize  = 32, Target.ClosureElementSize  = 1.
>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>
>>
>>
>>   - Jay
>>
>>
>  		 	   		  


From jay.krell at cornell.edu  Thu May 27 01:27:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 23:27:11 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <4BFDA90A.3050105@lcwb.coop>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>, ,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>
Message-ID: <COL101-W555E980AF6D3E51F8224B6E6E90@phx.gbl>


Rodney, if it doesn't work at all, and hasn't been worked on in a while, it should probably be removed.
If it works sometimes, ok.
If it say if (false) or #if 0, then it can be removed.
 If enabling that code provides something that sometimes work, why don't we just enable it always?
 Does it sometimes crash or have other bad properties?
 
 
I'm not just removing stuff, I'm also merging with 4.5.
The more we have, the more there is to merge.
Anything to reduce that work, even if it isn't huge in the first place, is good.
 [hypocrisy by me here]
 Dead code bears increasing cost, as we merge with more versions.
 
 
As well, if we are ever to be a gcc "plugin", we can't have any diffs. 
  "gcc plugin" is a new 4.5 feature.
I'm not sure this is a goal or viable, granted.
 
 
 
I don't like waiting for m3gdb to build and it isn't supported on some platforms e.g. Darwin.
I do want to see my data, but I'm skeptical it should require much or any changes to the debugger.
Esp. given that the changes to the compiler are pretty small.
Partly this is leftover from when I used Cygwin more -- everything (involving fork) is slow there.
 
 
 
There is part of the code that doesn't appear to be just about debugging and doesn't merge obviously.
The code it is in has been changed a lot, to iterate over a different form of data.
That I need I think I need to understand.
It appears, I think, that every single function call in Modula-3 has its codegen altered.
 Not just through pointers.
 It appears that way, and that is also my read of the m3back code, though I haven't yet looked at the generated code to confirm...and all my stepping through code in the past..I never noticed.
 
 
 
> Only calling procedures through a procedure-typed _parameter_ is
> slowed down. Calling through a procedure-typed _variable_ is known,

 
 Why are parameters different than variables?
 Can't I store a parameter in a variable? Even a local one? 
 Maybe not, because that might have bad "lifetime" and bad "safety"?
 
 
 
 Isn't every call through a function pointer affected?
 
 
What ATL does, you would call a "trampoline", but it isn't stored on the stack.
They call VirtualAlloc() which among the read/write flags includes an executable flag.
  At least on newer versions of Windows.
Since VirtualAlloc is expensive, as well as VirtualAlloc allocating in 64K chunk and the trampolines being small, a cache is maintained, as well as a presumably a sub-allocator being employed.
 
 
(If you think about it, you realize that there has *always* been some way to do this -- the linker writes a file and that file is executable. It could be "temporary", need not ever hit the disk.)
 
 
 - Jay



----------------------------------------
> Date: Wed, 26 May 2010 18:04:42 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
>
>
> Jay K wrote:
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>
>>>
>>>
>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions,
>
> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>
>>
>> Right..for those that don't know..
>>
>>
>> There's no "good" efficient way to implement nested functions.
>> Our implementation is pretty "bad".
>> gcc's implementation is pretty "bad".
>
> I think this is far too critical. The inefficiencies you see are
> minor. Certainly no worse than the implementation of dispatching
> methods of objects, something the world is gaga about. And the
> inefficiencies I think you are worrying about only arise when
> you pass procedures as parameters.
>
>
>
>
>> They are different.
>>
>>
>> gcc (Tony mentions "trampoline"):
>> In particular, taking the address of a nested function
>> involves runtime code generation on the stack.
>> These days, running code on the stack is "difficult".
>> On some systems, you do mprotect() to make that part of the stack executable.
>> On other systems, you just can't do it (iPhone).
>> On older systems, no problem. It is simple and efficient.
>>
>
> Yes, that is one consequence of trampolines. There has to be a place
> to generate code at runtime that will be executable, and a way to
> memory-manage it.
>
>>
>> Modula-3:
>> Whenever we go to call a function pointer, we first see if it start with a 4 or 8 byte -1.
>> If so, it is our "closure" thingy, and the -1 is followed
>> I guess by an actual function pointer and a static link.
>> The static link is loaded wherever and the function called.
>>
>>
>> Other systems (see modern ATL on Windows) allocate executable
>> memory not on the stack. Not even regular heap is executable
>> generally any longer though, one need to VirtualAlloc or mmap or such.
>>
>>
>> This is a powerful mechanism in general, you can do stuff like
>> runtime "currying".
>>
>>
>> Pointers to nested Modula-3 function cannot be passed off
>> as function pointers to other languages.
>> But hey, at least we can write nested functions and pass
>> them off to ourselves. Interop with C would just be bonus?
>>
>
> But if we used trampolines instead of our form of closures, they
> could be. Or, more generally, if we used the same mechanism as
> "other languages", they could be.
>
>>
>> Calling function pointers in Modula-3 is slowed down
>> everywhere, in case the function pointer is nested.
>> I think.
>
> Only calling procedures through a procedure-typed _parameter_ is
> slowed down. Calling through a procedure-typed _variable_ is known,
> by language semantics, always to be to a top-level procedure, and
> is as fast as a C call to a non-nested function pointer.
> Note that, when calling a function pointer to a nested procedure,
> trampolines are surely about as fast as you can get.
>
>>
>>
>> -1 must be ensured to be invalid code.
>> Or we could make it a more visible part of porting.
>> You know -- it could be per-target and folks would have
>> to experiment with each target to find a good sequence,
>> that is cheap to detect and guaranteed invalid.
>> (ie: 0 might be better than -1!)
>>
>>
>> Could possibly replace the -1 with an actual function pointer
>> that is always called.
>> But then pointers to non-nested functions also wouldn't
>> interoperate with C.
>
> I don't understand what mechanism you are proposing here. Taken
> literally, it sounds like a trampoline to me, which would allow
> non-nested and nested function pointers to interoperate with C.
>
>>
>>
>> I think there's something more to the mechanisms than I realize.
>> The "static link" must survive calls out to non-nested functions
>> or somesuch.
>>
>>
>> Anyway, while I think our mechanism is pretty clearly flawed,
>> it seems to be slightly less bad than gcc's.
>>
>
> I'm not sure what you mean by flawed, but if you mean it doesn't
> correctly implement language semantics, that is not true. It works
> correctly. So do trampolines, although in C (for other reasons that
> are independent of what mechanism you use for function pointers),
> the semantics of the language have a big hole. As usual, C passes
> the buck by defining this as "undefined".
>
>>
>> Perhaps we should invest in what ATL does though and
>> dynamically allocate executable memory not on the stack?
>
> If there is a way to do this, then trampolines can be made to work.
> What does gcc do now on such targets?
>
>> Still, an "open" iPhone is probably better with the current scheme.
>> Most other systems should be ok either way.
>>
>>
>> I think there is a bit of 4.3=>4.5 that needs closer attention
>> and isn't obvious, this part:
>>
>> + case STATIC_CHAIN_EXPR:
>> + decl = TREE_OPERAND (t, 0);
>> + target_context = decl_function_context (decl);
>> + if (target_context)
>> + {
>> + if (info->context == target_context)
>> + {
>> + /* Make sure frame_decl gets created. */
>> + (void) get_frame_type (info);
>> + }
>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>> + }
>> + else
>> + *tp = null_pointer_node;
>> + break;
>> +
>>
>> - Jay
>>
>
> Jay, you have made it clear repeatedly that you only use gdb, and
> never m3gdb, so obviously, Modula-3-specific support is of no importance
> to you. That's OK, but please don't spoil the game for those of us
> who do care about it by ripping stuff out of the compiler that m3gdb
> needs. Even when it isn't fully working yet.
>
> 		 	   		  

From jay.krell at cornell.edu  Thu May 27 01:38:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 26 May 2010 23:38:09 +0000
Subject: [M3devel] closure marker
In-Reply-To: <4BFDACC6.6020600@lcwb.coop>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>,
	<4BFDACC6.6020600@lcwb.coop>
Message-ID: <COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>


Rodney, It's not a data size optimization. It is a code size optimization.
Adding the padding is ok.
 
 
 
See Aligned_procedures use in.
http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
 
PROCEDURE If_closure (proc: Val;  true, false: Label;  freq: Frequency) =
  VAR skip := Next_label ();  nope := skip;
  BEGIN
    IF (false # No_label) THEN  nope := false; END;
    IF NOT Target.Aligned_procedures THEN
      Push (proc);
      Force ();
      cg.loophole (Type.Addr, Target.Integer.cg_type);
      Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
      cg.and (Target.Integer.cg_type);
      cg.if_true (Target.Integer.cg_type, nope, Always - freq);
      SPop (1, "If_closure-unaligned");
    END;
    Push (proc);
    Boost_alignment (Target.Address.align);
    Force ();
    cg.load_nil ();
    cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
    Push (proc);
    Boost_alignment (Target.Integer.align);
    Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
    Push_int (M3RT.CL_marker_value);
    IF (true # No_label)
      THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
      ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
    END;
    Set_label (skip);
    SPop (2, "If_closure");
  END If_closure;
 
 
Aligned_procedures would become effectively always true.
Code would be reduced.
 
 
I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
 
 
 - Jay



----------------------------------------
> Date: Wed, 26 May 2010 18:20:38 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
> After the marker, a closure also has two pointers, one to executable code,
> and one to an environment of nonlocal variables. These will always have
> to be aligned to whatever pointers require on the target. So making the
> marker smaller than a native pointer would then require padding the
> closure to get the pointers aligned. This uses as much space as just
> keeping the marker word-sized.
>
> And no, I don't think it makes any sense to (on a 64-bit target) start
> a closure on an odd multiple of 4 bytes, just so you can make the marker
> smaller while keeping the following pointers word-aligned.
>
> Jay K wrote:
>> A little bit of research done (just searching the web):
>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>
>>
>> all appear to use a 32bit instruction
>> presumably aligned but I couldn't confirm for all of them.
>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>
>>
>> Looks like SH has 16bit instructions.
>>
>>
>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>> With IA64 the expected exception with size=64bits, count=2.
>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>> We can revisit at that time.
>> And really size=64, count=1 might suffice.
>>
>> I'm a little torn.
>> A 64bit marker is more certain.
>> Code has been this way forever.
>> etc.
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>> Subject: closure marker
>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>
>>>
>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>> 64bit systems that care about alignment pay quite a penality imho.
>>>
>>>
>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>
>>>
>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>
>>>
>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>
>>>
>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>
>>>
>>> More general might be
>>> Target.ClosureElementSize (bits)
>>> Target.ClosureElementCount
>>>
>>>
>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>
>>>
>>>
>>> - Jay
>>>
>>>
>> 		 	   		  

From mika at async.async.caltech.edu  Thu May 27 02:11:33 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 26 May 2010 17:11:33 -0700
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W555E980AF6D3E51F8224B6E6E90@phx.gbl> 
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>, ,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>
	<COL101-W555E980AF6D3E51F8224B6E6E90@phx.gbl>
Message-ID: <20100527001133.7A5831A207D@async.async.caltech.edu>

Jay K writes:
...
>=20
> Why are parameters different than variables?
> Can't I store a parameter in a variable? Even a local one?=20
> Maybe not=2C because that might have bad "lifetime" and bad "safety"?
...

No you can't assign a procedure parameter that came from an inner
procedure to a variable.

In the below example, the activation record for A is already destroyed
when I call b().  It's still there in C.

TYPE P = PROCEDURE();

VAR a,b : P;

PROCEDURE A() =

  PROCEDURE B() = BEGIN END B;

  PROCEDURE C(p : P) = BEGIN p() END C;

  BEGIN
    C(B);   (* OK *)
    b := B; (* BAD! *)
  END A;

BEGIN
  a := A;
  a(); (* OK *)
  b(); (* ERROR *)
END.

The runtime does check for this.  It aborts at (* BAD! *)

  
    Mika


From hosking at cs.purdue.edu  Thu May 27 11:27:56 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 05:27:56 -0400
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>,
	<4BFDA293.9080503@lcwb.coop>
	<COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>
Message-ID: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>

Argh!!!!!
No!  We don't want to do work in the front-end to get rid of nesting.
It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.



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 26 May 2010, at 18:53, Jay K wrote:

> 
> Rodney, When you get back to it, can you just dig it out of history?
> 
> 
> I still think we should try to avoid gcc's nested function functionality.
> 
> 
> Where you use the static chain, not using the nested function functionality should
> "automatically" be debuggable -- "automatic" as in, once the work is done
> in the frontend to transform out nesting.
> 
> 
> "debuggable" as in, you could follow the links yourself in the debugger.
> The debugger need not search lexically nested functions that have function
> calls dividing them.
> 
> 
> ?
> 
> 
> There's stuff I still need to understand better -- particularly the affect of nested functions
> on non-nested functions. Is there *always* an extra parameter to *all* functions?
> It appears so.
> And I haven't figured out how to merge with 4.5 what I think achieves that.
> 
> 
> Maybe a good test of test cases here?
> 
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> Date: Wed, 26 May 2010 17:37:07 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>> 
>> I left it in because it is a work in progress. I *really* want to get it to
>> work, and I don't what to have to reinvent what is already there when I get
>> to it. I use nested procedures extensively in certain situations, and good
>> debugger support of them is important to me. It all works fine on older code
>> generators than the gcc that added tree-nested.c.
>> 
>> Jay K wrote:
>>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>>> Does it work?
>>> Does it accomplish anything?
>>> Can I remove it and its calls?
>>> 
>>> /* Special-purpose function to write stabs for the static_chain_decl.
>>> So far, this is not working. m3gdb needs the place in the activation
>>> record where the SL is stored. Right now, the SL is not necessarily
>>> stored at all, but may just be kept in a register. DECL_RTL and
>>> DECL_INCOMING_RTL may both have register expressions. But stabs
>>> entries for register variables, of kind N_RSYM, are currently ignored
>>> by gdb in dbxread.c, and making it read them could create problems
>>> elsewhere, because there can be other variables for which both an
>>> N_RSYM and an N_LSYM stabs entry are created.
>>> */
>>> static int
>>> dbxout_static_chain_decl (tree decl)
>>> 
>>> It was added 19 months ago by:
>>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>> 
>>> as well, do we need the #if 0 code added then?
>>> 
>>> - Jay
>>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu May 27 11:32:19 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 05:32:19 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W50960886C3E99F184DBA1CE6E90@phx.gbl>
References: <COL101-W5824E4C1B09A1384DAC5B0E6E90@phx.gbl>,
	<88534EB3-DF12-4CB8-96D7-445D5FD1FB64@cs.purdue.edu>
	<COL101-W50960886C3E99F184DBA1CE6E90@phx.gbl>
Message-ID: <2329B0DA-0FA5-4C74-9C12-A0CDFE35BADE@cs.purdue.edu>



On 26 May 2010, at 18:56, Jay K wrote:

> 
>>> Nested functions should be transformed to not be nested. Imho.
> 
>> I don't understand this. Nested functions must be nested in the sense that
>> they have static chain information provided by gcc.
> 
> 
> 
> Can it be achieved by adding an extra parameter instead?

The compiler *does* (inside gcc) add an extra parameter.

> 
> 
>>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
>> What do you mean by this?
> 
> 
> 
> It looks like we inhibit optimization if -g is specified.
> Like we preserve unused static chains.
> This is has been discussed and I have to look at the code more..
> Generating debug information should not inhibit optimisation.

Generating debug information inhibits optimisations where sufficient state needs to be kept around to support symbolic debugging.  I don't think it inhibits optimisation in any way we care about.

> 
> 
> 
> - Jay
> 
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 26 May 2010 10:26:32 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>> 
>> On 26 May 2010, at 03:55, Jay K wrote:
>> 
>>> 
>>> I'm going to try to keep the code that seems to do anything, however:
>>> 
>>> 1) if (false &&
>>> 
>>> I plan to remove that.
>>> 
>>> 
>>> 2)
>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>> +/* REMOVE ME: */
>>> + /* && !debug_static_links () */
>>> + )
>>> 
>>> 
>>> I can't find where that would apply, and it is commented out anyway so I'll remove it.
>>> 
>>> 
>>> I'm open to arguments though. :)
>>> 
>>> dbxout.c
>>> +#if 0
>>> +/* Code copied from 1.4.2.2: */
>>> 
>>> 
>>> I can cheaply enough keep that...should we really though?
>>> 
>>> 
>>> I really think we can reduce our changes.
>>> Enough type information should be passed around so that regular gdb works. Imho.
>> 
>> Possibly, but M3 has a very different notion of type to C. Moreover, it is extremely valuable to have the M3 type ids there so that functionality can map back to the types in the M3 runtime system. It would be possible to implement much of the m3gdb debugging support by calling back into the language run-time passing the language type ids instead of relying on hand-crafted C in m3gdb. But I agree that more type information would be good, particularly for records.
>> 
>>> And so that we can use Dwarf or regular -g -- ie. so various -g options other than -gstabs
>>> don't cause internal compiler errors. So that debug info might be generated on systems
>>> that don't support stabs though granted they are few and minor (hppa64-hpux).
>>> Nested functions should be transformed to not be nested. Imho.
>> 
>> I don't understand this. Nested functions must be nested in the sense that they have static chain information provided by gcc.
>> 
>>> Optimization should be allowed to inhibit debugging as much as it does for any other language.
>> 
>> What do you mean by this?
>> 
>>> 
>>> 
>>> I realize the type information getting around is probably a lot of work.
>>> And it is needed in m3back also, and probably not shared work.
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Subject: m3cc static chain stuff
>>>> Date: Wed, 26 May 2010 06:05:25 +0000
>>>> 
>>>> 
>>>> Can any of this be removed?
>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>> generally a considered the responsibility of optimizers.
>>>> 
>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>> Maybe I'll try without.
>>>> 
>>>> 
>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>> 
>>>> 
>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3-util.c */
>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>> +
>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>> be adding fields as necessary.
>>>> 
>>>> We also build the DECL that represents this frame in the function. */
>>>> @@ -209,7 +224,8 @@
>>>> free (name);
>>>> 
>>>> info->frame_type = type;
>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>> + info->frame_decl
>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>> 
>>>> /* ??? Always make it addressable for now, since it is meant to
>>>> be pointed to by the static chain pointer. This pessimizes
>>>> @@ -218,6 +234,8 @@
>>>> reachable, but the true pessimization is to create the non-
>>>> local frame structure in the first place. */
>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (info->frame_decl) = 0;
>>>> }
>>>> return type;
>>>> }
>>>> @@ -290,6 +308,10 @@
>>>> return *slot;
>>>> }
>>>> 
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_var_name = "_static_link_var";
>>>> +
>>>> /* Build or return the variable that holds the static chain within
>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>> 
>>>> @@ -310,9 +332,14 @@
>>>> Note also that it's represented as a parameter. This is more
>>>> close to the truth, since the initial value does come from
>>>> the caller. */
>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>> + decl = build_decl
>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>> DECL_ARTIFICIAL (decl) = 1;
>>>> - DECL_IGNORED_P (decl) = 1;
>>>> +
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (decl) = 0;
>>>> +
>>>> TREE_USED (decl) = 1;
>>>> DECL_CONTEXT (decl) = info->context;
>>>> DECL_ARG_TYPE (decl) = type;
>>>> @@ -326,7 +353,11 @@
>>>> return decl;
>>>> }
>>>> 
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>> +
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>> multiple nesting levels. */
>>>> 
>>>> @@ -339,10 +370,12 @@
>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>> 
>>>> field = make_node (FIELD_DECL);
>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>> TREE_TYPE (field) = type;
>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>> + /* m3gdb should know about this field. */
>>>> + DECL_IGNORED_P (field) = 0;
>>>> 
>>>> insert_field_into_struct (get_frame_type (info), field);
>>>> 
>>>> @@ -465,7 +498,7 @@
>>>> return *slot;
>>>> }
>>>> 
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>> rtl middle-end as dynamic stack space is allocated. */
>>>> 
>>>> @@ -1620,6 +1653,9 @@
>>>> switch (TREE_CODE (t))
>>>> {
>>>> case ADDR_EXPR:
>>>> + if (TREE_STATIC (t))
>>>> + break;
>>>> +
>>>> /* Build
>>>> T.1 = &CHAIN->tramp;
>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>> @@ -1714,6 +1750,22 @@
>>>> }
>>>> break;
>>>> 
>>>> + case STATIC_CHAIN_EXPR:
>>>> + decl = TREE_OPERAND (t, 0);
>>>> + target_context = decl_function_context (decl);
>>>> + if (target_context)
>>>> + {
>>>> + if (info->context == target_context)
>>>> + {
>>>> + /* Make sure frame_decl gets created. */
>>>> + (void) get_frame_type (info);
>>>> + }
>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>> + }
>>>> + else
>>>> + *tp = null_pointer_node;
>>>> + break;
>>>> +
>>>> case RETURN_EXPR:
>>>> case GIMPLE_MODIFY_STMT:
>>>> case WITH_SIZE_EXPR:
>>>> @@ -1768,13 +1820,22 @@
>>>> return NULL_TREE;
>>>> }
>>>> 
>>>> +static bool
>>>> +debug_static_links (void)
>>>> +{ return
>>>> + write_symbols != NO_DEBUG
>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>> +
>>>> +} /* debug_static_links */
>>>> +
>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>> trampolines and call expressions. On the way back up, determine if
>>>> a nested function actually uses its static chain; if not, remember that. */
>>>> 
>>>> static void
>>>> convert_all_function_calls (struct nesting_info *root)
>>>> -{
>>>> +{
>>>> do
>>>> {
>>>> if (root->inner)
>>>> @@ -1784,7 +1845,10 @@
>>>> walk_function (convert_call_expr, root);
>>>> 
>>>> /* If the function does not use a static chain, then remember that. */
>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>> +/* REMOVE ME: */
>>>> + /* && !debug_static_links () */
>>>> + )
>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>> else
>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>> @@ -1806,6 +1870,21 @@
>>>> tree context = root->context;
>>>> struct function *sf;
>>>> 
>>>> +/* REMOVEME: */
>>>> + /* If this is a nested function and we are supporting debugging via
>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>> + chain, even if the programmer's code doesn't use it. */
>>>> + if (false && root->outer && debug_static_links () )
>>>> + { tree static_chain_decl, temp, stmt;
>>>> + /* This is a desperate attempt to get later code generation to
>>>> + store the static link. If it works, it'll be a miracle. */
>>>> + static_chain_decl = get_chain_decl (root);
>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>> + append_to_statement_list (stmt, &stmt_list);
>>>> + }
>>>> +
>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>> out at this time. */
>>>> if (root->frame_type)
>>>> @@ -1912,7 +1991,7 @@
>>>> proper BIND_EXPR. */
>>>> if (root->new_local_var_chain)
>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>> - false);
>>>> + true);
>>>> if (root->debug_var_chain)
>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>> true);
>>>> 
>>>> 
>>>> 
>>> 
>> 		 	   		  

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

From hosking at cs.purdue.edu  Thu May 27 11:33:52 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 05:33:52 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <4BFDAB5A.6000304@lcwb.coop>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
	<4BFDAB5A.6000304@lcwb.coop>
Message-ID: <D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>

The trampoline mechanism is broken on many platforms because they disable executable stacks.  I strongly favour retaining the current mechanisms.

On 26 May 2010, at 19:14, Rodney M. Bates wrote:

> 
> 
> Tony Hosking wrote:
>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible.  The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
> 
> I don't follow the last part of this argument.  If we follow the first
> principle, we would just use trampolines, since they are the same
> mechanism the C compiler uses.  And the only place they are not possible
> are places where they won't work for C either (e.g., a target where there
> is no place to construct code at runtime and have it be executable).
> The mere fact that we "also build closures" is not a necessity, just
> the reflection of the design decision to use the closure mechanism
> instead of trampolines.
> 
> OTHO, despite all the positive things I have said here and in another post
> about trampolines, I don't favor using them, because they would make m3gdb
> support a lot more difficult.  m3gdb needs to be able to both read and
> construct closures/trampolines, whichever.  Closures are almost target-
> independent, except for the native word size, which is already easily
> available to m3gdb.  Trampolines are going to be different for every
> instruction set, and the ones constructed by compiled code, at least,
> could even change with compiler version.  m3gdb would need a _lot_ of
> highly target-dependent code to handle them.
> 
>> 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 26 May 2010, at 02:05, Jay K wrote:
>>> 
>>> Can any of this be removed?
>>> Can we really not just use "unfold-nested-procs" like NT386?
>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>> generally a considered the responsibility of optimizers.
>>> 
>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>> Maybe I'll try without.
>>> 
>>> 
>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c    2008-02-15 09:36:43.000000000 -0800
>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c    2010-05-09 22:27:58.000000000 -0700
>>> 
>>> 
>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>> -   shared between INFO->CONTEXT and its nested functions.  This record will
>>> -   not be complete until finalize_nesting_tree; up until that point we'll
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> +   m3-util.c */
>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>> +
>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>> +   that is shared between INFO->CONTEXT and its nested functions.  This record
>>> +   will not be complete until finalize_nesting_tree; up until that point we'll
>>>    be adding fields as necessary.
>>>     We also build the DECL that represents this frame in the function.  */
>>> @@ -209,7 +224,8 @@
>>>       free (name);
>>>        info->frame_type = type;
>>> -      info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>> +      info->frame_decl
>>> +        = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>        /* ??? Always make it addressable for now, since it is meant to
>>>      be pointed to by the static chain pointer.  This pessimizes
>>> @@ -218,6 +234,8 @@
>>>      reachable, but the true pessimization is to create the non-
>>>      local frame structure in the first place.  */
>>>       TREE_ADDRESSABLE (info->frame_decl) = 1;
>>> +      /* m3gdb needs to know about this variable. */
>>> +      DECL_IGNORED_P (info->frame_decl) = 0;      }
>>>   return type;
>>> }
>>> @@ -290,6 +308,10 @@
>>>   return *slot;
>>> }
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> +   m3_util.c */
>>> +static const char * static_link_var_name = "_static_link_var";
>>> +
>>> /* Build or return the variable that holds the static chain within
>>>    INFO->CONTEXT.  This variable may only be used within INFO->CONTEXT.  */
>>> @@ -310,9 +332,14 @@
>>>      Note also that it's represented as a parameter.  This is more
>>>      close to the truth, since the initial value does come from
>>>      the caller.  */
>>> -      decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>> +      decl = build_decl
>>> +               (PARM_DECL, get_identifier (static_link_var_name), type);
>>> +      TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>       DECL_ARTIFICIAL (decl) = 1;
>>> -      DECL_IGNORED_P (decl) = 1;
>>> +
>>> +      /* m3gdb needs to know about this variable. */
>>> +      DECL_IGNORED_P (decl) = 0;
>>> +
>>>       TREE_USED (decl) = 1;
>>>       DECL_CONTEXT (decl) = info->context;
>>>       DECL_ARG_TYPE (decl) = type;
>>> @@ -326,7 +353,11 @@
>>>   return decl;
>>> }
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>> +   m3_util.c */
>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>> +
>>> +/* Build or return the field within the non-local frame struct that holds
>>>    the static chain for INFO->CONTEXT.  This is the way to walk back up
>>>    multiple nesting levels.  */
>>> @@ -339,10 +370,12 @@
>>>       tree type = build_pointer_type (get_frame_type (info->outer));
>>>        field = make_node (FIELD_DECL);
>>> -      DECL_NAME (field) = get_identifier ("__chain");
>>> +      DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>       TREE_TYPE (field) = type;
>>>       DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>       DECL_NONADDRESSABLE_P (field) = 1;
>>> +      /* m3gdb should know about this field. */
>>> +      DECL_IGNORED_P (field) = 0;         insert_field_into_struct (get_frame_type (info), field);
>>> @@ -465,7 +498,7 @@
>>>   return *slot;
>>> }
>>> -/* Build or return the field within the non-local frame state that holds
>>> +/* Build or return the field within the non-local frame struct that holds
>>>    the non-local goto "jmp_buf".  The buffer itself is maintained by the
>>>    rtl middle-end as dynamic stack space is allocated.  */
>>> @@ -1620,6 +1653,9 @@
>>>   switch (TREE_CODE (t))
>>>     {
>>>     case ADDR_EXPR:
>>> +      if (TREE_STATIC (t))
>>> +    break;
>>> +
>>>       /* Build
>>>        T.1 = &CHAIN->tramp;
>>>        T.2 = __builtin_adjust_trampoline (T.1);
>>> @@ -1714,6 +1750,22 @@
>>>     }
>>>       break;
>>> +    case STATIC_CHAIN_EXPR:
>>> +      decl = TREE_OPERAND (t, 0);
>>> +      target_context = decl_function_context (decl);
>>> +      if (target_context)
>>> +    {
>>> +      if (info->context == target_context)
>>> +        {
>>> +          /* Make sure frame_decl gets created.  */
>>> +          (void) get_frame_type (info);
>>> +        }
>>> +      *tp = get_static_chain (info, target_context, &wi->tsi);
>>> +    }
>>> +      else
>>> +    *tp = null_pointer_node;
>>> +      break;
>>> +
>>>     case RETURN_EXPR:
>>>     case GIMPLE_MODIFY_STMT:
>>>     case WITH_SIZE_EXPR:
>>> @@ -1768,13 +1820,22 @@
>>>   return NULL_TREE;
>>> }
>>> +static bool
>>> +debug_static_links (void)
>>> +{ return
>>> +    write_symbols != NO_DEBUG
>>> +    && debug_info_level != DINFO_LEVEL_NONE
>>> +    && debug_info_level != DINFO_LEVEL_TERSE;
>>> +
>>> +} /* debug_static_links */
>>> +
>>> /* Walk the nesting tree starting with ROOT, depth first.  Convert all
>>>    trampolines and call expressions.  On the way back up, determine if
>>>    a nested function actually uses its static chain; if not, remember that.  */
>>>  static void
>>> convert_all_function_calls (struct nesting_info *root)
>>> -{
>>> +{
>>>   do
>>>     {
>>>       if (root->inner)
>>> @@ -1784,7 +1845,10 @@
>>>       walk_function (convert_call_expr, root);
>>>        /* If the function does not use a static chain, then remember that.  */
>>> -      if (root->outer && !root->chain_decl && !root->chain_field)
>>> +      if (root->outer && !root->chain_decl && !root->chain_field
>>> +/* REMOVE ME: */
>>> +          /* && !debug_static_links () */
>>> +         )
>>>     DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>       else
>>>     gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>> @@ -1806,6 +1870,21 @@
>>>   tree context = root->context;
>>>   struct function *sf;
>>> +/* REMOVEME: */
>>> +  /* If this is a nested function and we are supporting debugging via
>>> +     m3gdb, we always need a chain_decl, so m3gdb can find the static
>>> +     chain, even if the programmer's code doesn't use it. */
>>> +  if (false && root->outer && debug_static_links () )
>>> +    { tree static_chain_decl, temp, stmt;
>>> +      /* This is a desperate attempt to get later code generation to
>>> +         store the static link.  If it works, it'll be a miracle. */
>>> +      static_chain_decl = get_chain_decl (root);
>>> +      stmt = build_addr (static_chain_decl, root->context);
>>> +      temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>> +      stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>> +      append_to_statement_list (stmt, &stmt_list);
>>> +    }
>>> +
>>>   /* If we created a non-local frame type or decl, we need to lay them
>>>      out at this time.  */
>>>   if (root->frame_type)
>>> @@ -1912,7 +1991,7 @@
>>>      proper BIND_EXPR.  */
>>>   if (root->new_local_var_chain)
>>>     declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>> -          false);
>>> +          true);
>>>   if (root->debug_var_chain)
>>>     declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>           true);
>>> 
>>> 
>>>    



From jay.krell at cornell.edu  Thu May 27 13:27:44 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 11:27:44 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
Message-ID: <col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>


I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
 
 
I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
  Because it has a similar but inferior mechanism.
 
 
One wonders about Ada though -- does it supported nested functions?
  I noticed it bears a striking resembles to Pascal/Modula-3. :)
 
And uses the same not great trampoline mechanism?
 
 
If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
Those are two very big ifs.
 
 
Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?
Ah.
We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
 
                             -- pointer to function --
                             -- parameter/static chain whatever --
 trampoline points here =>   -- start of code --
                             -- target dependent position independent not very optimized
                             -- *constant* hand crafted code that fetchs the data from just before itself
 
 
Would that address the m3gdb problem?
 Putting the data at fixed negative offsets from the trampoline code?
 Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
  to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
 
 
Granted, crafting that code would be.. fun. :)
Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 05:33:52 -0400
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>
> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>
>>
>>
>> Tony Hosking wrote:
>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>
>> I don't follow the last part of this argument. If we follow the first
>> principle, we would just use trampolines, since they are the same
>> mechanism the C compiler uses. And the only place they are not possible
>> are places where they won't work for C either (e.g., a target where there
>> is no place to construct code at runtime and have it be executable).
>> The mere fact that we "also build closures" is not a necessity, just
>> the reflection of the design decision to use the closure mechanism
>> instead of trampolines.
>>
>> OTHO, despite all the positive things I have said here and in another post
>> about trampolines, I don't favor using them, because they would make m3gdb
>> support a lot more difficult. m3gdb needs to be able to both read and
>> construct closures/trampolines, whichever. Closures are almost target-
>> independent, except for the native word size, which is already easily
>> available to m3gdb. Trampolines are going to be different for every
>> instruction set, and the ones constructed by compiled code, at least,
>> could even change with compiler version. m3gdb would need a _lot_ of
>> highly target-dependent code to handle them.
>>
>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>
>>>> Can any of this be removed?
>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>> generally a considered the responsibility of optimizers.
>>>>
>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>> Maybe I'll try without.
>>>>
>>>>
>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>
>>>>
>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3-util.c */
>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>> +
>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>> be adding fields as necessary.
>>>> We also build the DECL that represents this frame in the function. */
>>>> @@ -209,7 +224,8 @@
>>>> free (name);
>>>> info->frame_type = type;
>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>> + info->frame_decl
>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>> /* ??? Always make it addressable for now, since it is meant to
>>>> be pointed to by the static chain pointer. This pessimizes
>>>> @@ -218,6 +234,8 @@
>>>> reachable, but the true pessimization is to create the non-
>>>> local frame structure in the first place. */
>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>> return type;
>>>> }
>>>> @@ -290,6 +308,10 @@
>>>> return *slot;
>>>> }
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_var_name = "_static_link_var";
>>>> +
>>>> /* Build or return the variable that holds the static chain within
>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>> @@ -310,9 +332,14 @@
>>>> Note also that it's represented as a parameter. This is more
>>>> close to the truth, since the initial value does come from
>>>> the caller. */
>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>> + decl = build_decl
>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>> DECL_ARTIFICIAL (decl) = 1;
>>>> - DECL_IGNORED_P (decl) = 1;
>>>> +
>>>> + /* m3gdb needs to know about this variable. */
>>>> + DECL_IGNORED_P (decl) = 0;
>>>> +
>>>> TREE_USED (decl) = 1;
>>>> DECL_CONTEXT (decl) = info->context;
>>>> DECL_ARG_TYPE (decl) = type;
>>>> @@ -326,7 +353,11 @@
>>>> return decl;
>>>> }
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>> + m3_util.c */
>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>> +
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>> multiple nesting levels. */
>>>> @@ -339,10 +370,12 @@
>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>> field = make_node (FIELD_DECL);
>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>> TREE_TYPE (field) = type;
>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>> + /* m3gdb should know about this field. */
>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>> @@ -465,7 +498,7 @@
>>>> return *slot;
>>>> }
>>>> -/* Build or return the field within the non-local frame state that holds
>>>> +/* Build or return the field within the non-local frame struct that holds
>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>> rtl middle-end as dynamic stack space is allocated. */
>>>> @@ -1620,6 +1653,9 @@
>>>> switch (TREE_CODE (t))
>>>> {
>>>> case ADDR_EXPR:
>>>> + if (TREE_STATIC (t))
>>>> + break;
>>>> +
>>>> /* Build
>>>> T.1 = &CHAIN->tramp;
>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>> @@ -1714,6 +1750,22 @@
>>>> }
>>>> break;
>>>> + case STATIC_CHAIN_EXPR:
>>>> + decl = TREE_OPERAND (t, 0);
>>>> + target_context = decl_function_context (decl);
>>>> + if (target_context)
>>>> + {
>>>> + if (info->context == target_context)
>>>> + {
>>>> + /* Make sure frame_decl gets created. */
>>>> + (void) get_frame_type (info);
>>>> + }
>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>> + }
>>>> + else
>>>> + *tp = null_pointer_node;
>>>> + break;
>>>> +
>>>> case RETURN_EXPR:
>>>> case GIMPLE_MODIFY_STMT:
>>>> case WITH_SIZE_EXPR:
>>>> @@ -1768,13 +1820,22 @@
>>>> return NULL_TREE;
>>>> }
>>>> +static bool
>>>> +debug_static_links (void)
>>>> +{ return
>>>> + write_symbols != NO_DEBUG
>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>> +
>>>> +} /* debug_static_links */
>>>> +
>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>> trampolines and call expressions. On the way back up, determine if
>>>> a nested function actually uses its static chain; if not, remember that. */
>>>> static void
>>>> convert_all_function_calls (struct nesting_info *root)
>>>> -{
>>>> +{
>>>> do
>>>> {
>>>> if (root->inner)
>>>> @@ -1784,7 +1845,10 @@
>>>> walk_function (convert_call_expr, root);
>>>> /* If the function does not use a static chain, then remember that. */
>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>> +/* REMOVE ME: */
>>>> + /* && !debug_static_links () */
>>>> + )
>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>> else
>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>> @@ -1806,6 +1870,21 @@
>>>> tree context = root->context;
>>>> struct function *sf;
>>>> +/* REMOVEME: */
>>>> + /* If this is a nested function and we are supporting debugging via
>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>> + chain, even if the programmer's code doesn't use it. */
>>>> + if (false && root->outer && debug_static_links () )
>>>> + { tree static_chain_decl, temp, stmt;
>>>> + /* This is a desperate attempt to get later code generation to
>>>> + store the static link. If it works, it'll be a miracle. */
>>>> + static_chain_decl = get_chain_decl (root);
>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>> + append_to_statement_list (stmt, &stmt_list);
>>>> + }
>>>> +
>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>> out at this time. */
>>>> if (root->frame_type)
>>>> @@ -1912,7 +1991,7 @@
>>>> proper BIND_EXPR. */
>>>> if (root->new_local_var_chain)
>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>> - false);
>>>> + true);
>>>> if (root->debug_var_chain)
>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>> true);
>>>>
>>>>
>>>>
> 		 	   		  

From jay.krell at cornell.edu  Thu May 27 13:31:20 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 11:31:20 +0000
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>, ,
	<4BFDA293.9080503@lcwb.coop>,
	<COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>,
	<665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
Message-ID: <COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>


Shouldn't gcc be able to optimize about as well any such transform?
  Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
 
Anyway, ok.
 
There's stuff I have to figure out and understand here either way.
 
Like, does the the static chain "flow" through non-nested calls?
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 05:27:56 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
>
>
> Argh!!!!!
> No! We don't want to do work in the front-end to get rid of nesting.
> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>
>
>
>
> 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 26 May 2010, at 18:53, Jay K wrote:
>
>
> Rodney, When you get back to it, can you just dig it out of history?
>
>
> I still think we should try to avoid gcc's nested function functionality.
>
>
> Where you use the static chain, not using the nested function functionality should
> "automatically" be debuggable -- "automatic" as in, once the work is done
> in the frontend to transform out nesting.
>
>
> "debuggable" as in, you could follow the links yourself in the debugger.
> The debugger need not search lexically nested functions that have function
> calls dividing them.
>
>
> ?
>
>
> There's stuff I still need to understand better -- particularly the affect of nested functions
> on non-nested functions. Is there *always* an extra parameter to *all* functions?
> It appears so.
> And I haven't figured out how to merge with 4.5 what I think achieves that.
>
>
> Maybe a good test of test cases here?
>
>
>
> - Jay
>
>
> ----------------------------------------
> Date: Wed, 26 May 2010 17:37:07 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
> I left it in because it is a work in progress. I *really* want to get it to
> work, and I don't what to have to reinvent what is already there when I get
> to it. I use nested procedures extensively in certain situations, and good
> debugger support of them is important to me. It all works fine on older code
> generators than the gcc that added tree-nested.c.
>
> Jay K wrote:
> Rodney, you added this function, along with a comment that says it doesn't actually work.
> Does it work?
> Does it accomplish anything?
> Can I remove it and its calls?
>
> /* Special-purpose function to write stabs for the static_chain_decl.
> So far, this is not working. m3gdb needs the place in the activation
> record where the SL is stored. Right now, the SL is not necessarily
> stored at all, but may just be kept in a register. DECL_RTL and
> DECL_INCOMING_RTL may both have register expressions. But stabs
> entries for register variables, of kind N_RSYM, are currently ignored
> by gdb in dbxread.c, and making it read them could create problems
> elsewhere, because there can be other variables for which both an
> N_RSYM and an N_LSYM stabs entry are created.
> */
> static int
> dbxout_static_chain_decl (tree decl)
>
> It was added 19 months ago by:
> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>
> as well, do we need the #if 0 code added then?
>
> - Jay
>
> 		 	   		  

From hosking at cs.purdue.edu  Thu May 27 14:10:50 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Thu, 27 May 2010 08:10:50 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
	<col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
Message-ID: <BC008F6B-61C8-481A-9927-2B23DC6D6909@cs.purdue.edu>

m3gdb doesn't read trampolines because the gcc-based backend does not generate them!


On 27 May 2010, at 07:27, Jay K wrote:

> 
> I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
> 
> 
> I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
>  Because it has a similar but inferior mechanism.
> 
> 
> One wonders about Ada though -- does it supported nested functions?
>  I noticed it bears a striking resembles to Pascal/Modula-3. :)
> 
> And uses the same not great trampoline mechanism?
> 
> 
> If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
> Those are two very big ifs.
> 
> 
> Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?
> Ah.
> We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
> 
>                             -- pointer to function --
>                             -- parameter/static chain whatever --
> trampoline points here =>   -- start of code --
>                             -- target dependent position independent not very optimized
>                             -- *constant* hand crafted code that fetchs the data from just before itself
> 
> 
> Would that address the m3gdb problem?
> Putting the data at fixed negative offsets from the trampoline code?
> Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
>  to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
> 
> 
> Granted, crafting that code would be.. fun. :)
> Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:33:52 -0400
>> To: rodney_bates at lcwb.coop
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>> 
>> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>> 
>> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>> 
>>> 
>>> 
>>> Tony Hosking wrote:
>>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>> 
>>> I don't follow the last part of this argument. If we follow the first
>>> principle, we would just use trampolines, since they are the same
>>> mechanism the C compiler uses. And the only place they are not possible
>>> are places where they won't work for C either (e.g., a target where there
>>> is no place to construct code at runtime and have it be executable).
>>> The mere fact that we "also build closures" is not a necessity, just
>>> the reflection of the design decision to use the closure mechanism
>>> instead of trampolines.
>>> 
>>> OTHO, despite all the positive things I have said here and in another post
>>> about trampolines, I don't favor using them, because they would make m3gdb
>>> support a lot more difficult. m3gdb needs to be able to both read and
>>> construct closures/trampolines, whichever. Closures are almost target-
>>> independent, except for the native word size, which is already easily
>>> available to m3gdb. Trampolines are going to be different for every
>>> instruction set, and the ones constructed by compiled code, at least,
>>> could even change with compiler version. m3gdb would need a _lot_ of
>>> highly target-dependent code to handle them.
>>> 
>>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>> 
>>>>> Can any of this be removed?
>>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>>> generally a considered the responsibility of optimizers.
>>>>> 
>>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>>> Maybe I'll try without.
>>>>> 
>>>>> 
>>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>> 
>>>>> 
>>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3-util.c */
>>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>>> +
>>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>>> be adding fields as necessary.
>>>>> We also build the DECL that represents this frame in the function. */
>>>>> @@ -209,7 +224,8 @@
>>>>> free (name);
>>>>> info->frame_type = type;
>>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>>> + info->frame_decl
>>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>>> /* ??? Always make it addressable for now, since it is meant to
>>>>> be pointed to by the static chain pointer. This pessimizes
>>>>> @@ -218,6 +234,8 @@
>>>>> reachable, but the true pessimization is to create the non-
>>>>> local frame structure in the first place. */
>>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>>> return type;
>>>>> }
>>>>> @@ -290,6 +308,10 @@
>>>>> return *slot;
>>>>> }
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_var_name = "_static_link_var";
>>>>> +
>>>>> /* Build or return the variable that holds the static chain within
>>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>>> @@ -310,9 +332,14 @@
>>>>> Note also that it's represented as a parameter. This is more
>>>>> close to the truth, since the initial value does come from
>>>>> the caller. */
>>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>>> + decl = build_decl
>>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>>> DECL_ARTIFICIAL (decl) = 1;
>>>>> - DECL_IGNORED_P (decl) = 1;
>>>>> +
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (decl) = 0;
>>>>> +
>>>>> TREE_USED (decl) = 1;
>>>>> DECL_CONTEXT (decl) = info->context;
>>>>> DECL_ARG_TYPE (decl) = type;
>>>>> @@ -326,7 +353,11 @@
>>>>> return decl;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>>> +
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>>> multiple nesting levels. */
>>>>> @@ -339,10 +370,12 @@
>>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>>> field = make_node (FIELD_DECL);
>>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>>> TREE_TYPE (field) = type;
>>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>>> + /* m3gdb should know about this field. */
>>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>>> @@ -465,7 +498,7 @@
>>>>> return *slot;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>>> rtl middle-end as dynamic stack space is allocated. */
>>>>> @@ -1620,6 +1653,9 @@
>>>>> switch (TREE_CODE (t))
>>>>> {
>>>>> case ADDR_EXPR:
>>>>> + if (TREE_STATIC (t))
>>>>> + break;
>>>>> +
>>>>> /* Build
>>>>> T.1 = &CHAIN->tramp;
>>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>>> @@ -1714,6 +1750,22 @@
>>>>> }
>>>>> break;
>>>>> + case STATIC_CHAIN_EXPR:
>>>>> + decl = TREE_OPERAND (t, 0);
>>>>> + target_context = decl_function_context (decl);
>>>>> + if (target_context)
>>>>> + {
>>>>> + if (info->context == target_context)
>>>>> + {
>>>>> + /* Make sure frame_decl gets created. */
>>>>> + (void) get_frame_type (info);
>>>>> + }
>>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>>> + }
>>>>> + else
>>>>> + *tp = null_pointer_node;
>>>>> + break;
>>>>> +
>>>>> case RETURN_EXPR:
>>>>> case GIMPLE_MODIFY_STMT:
>>>>> case WITH_SIZE_EXPR:
>>>>> @@ -1768,13 +1820,22 @@
>>>>> return NULL_TREE;
>>>>> }
>>>>> +static bool
>>>>> +debug_static_links (void)
>>>>> +{ return
>>>>> + write_symbols != NO_DEBUG
>>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>>> +
>>>>> +} /* debug_static_links */
>>>>> +
>>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>>> trampolines and call expressions. On the way back up, determine if
>>>>> a nested function actually uses its static chain; if not, remember that. */
>>>>> static void
>>>>> convert_all_function_calls (struct nesting_info *root)
>>>>> -{
>>>>> +{
>>>>> do
>>>>> {
>>>>> if (root->inner)
>>>>> @@ -1784,7 +1845,10 @@
>>>>> walk_function (convert_call_expr, root);
>>>>> /* If the function does not use a static chain, then remember that. */
>>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>>> +/* REMOVE ME: */
>>>>> + /* && !debug_static_links () */
>>>>> + )
>>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>>> else
>>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>>> @@ -1806,6 +1870,21 @@
>>>>> tree context = root->context;
>>>>> struct function *sf;
>>>>> +/* REMOVEME: */
>>>>> + /* If this is a nested function and we are supporting debugging via
>>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>>> + chain, even if the programmer's code doesn't use it. */
>>>>> + if (false && root->outer && debug_static_links () )
>>>>> + { tree static_chain_decl, temp, stmt;
>>>>> + /* This is a desperate attempt to get later code generation to
>>>>> + store the static link. If it works, it'll be a miracle. */
>>>>> + static_chain_decl = get_chain_decl (root);
>>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>>> + append_to_statement_list (stmt, &stmt_list);
>>>>> + }
>>>>> +
>>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>>> out at this time. */
>>>>> if (root->frame_type)
>>>>> @@ -1912,7 +1991,7 @@
>>>>> proper BIND_EXPR. */
>>>>> if (root->new_local_var_chain)
>>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>>> - false);
>>>>> + true);
>>>>> if (root->debug_var_chain)
>>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>>> true);
>>>>> 
>>>>> 
>>>>> 
>> 		 	   		  



From jay.krell at cornell.edu  Thu May 27 14:26:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 12:26:18 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <BC008F6B-61C8-481A-9927-2B23DC6D6909@cs.purdue.edu>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
	<col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>,
	<BC008F6B-61C8-481A-9927-2B23DC6D6909@cs.purdue.edu>
Message-ID: <COL101-W509A5F179B6BE9A4C4CD1FE6EA0@phx.gbl>


But, it reads closures?
And IF there was a reasonable portable "executable heap", and trampolines were put there..the debugability could be solved as described -- putting the parameter(s) at fixed negative offsets from the code?

?- Jay


----------------------------------------
> Subject: Re: [M3devel] m3cc static chain stuff
> From: hosking at cs.purdue.edu
> Date: Thu, 27 May 2010 08:10:50 -0400
> CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> m3gdb doesn't read trampolines because the gcc-based backend does not generate them!
>
>
> On 27 May 2010, at 07:27, Jay K wrote:
>
>>
>> I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
>>
>>
>> I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
>> Because it has a similar but inferior mechanism.
>>
>>
>> One wonders about Ada though -- does it supported nested functions?
>> I noticed it bears a striking resembles to Pascal/Modula-3. :)
>>
>> And uses the same not great trampoline mechanism?
>>
>>
>> If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
>> Those are two very big ifs.
>>
>>
>> Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?
>> Ah.
>> We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
>>
>> -- pointer to function --
>> -- parameter/static chain whatever --
>> trampoline points here => -- start of code --
>> -- target dependent position independent not very optimized
>> -- *constant* hand crafted code that fetchs the data from just before itself
>>
>>
>> Would that address the m3gdb problem?
>> Putting the data at fixed negative offsets from the trampoline code?
>> Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
>> to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
>>
>>
>> Granted, crafting that code would be.. fun. :)
>> Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Thu, 27 May 2010 05:33:52 -0400
>>> To: rodney_bates at lcwb.coop
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>
>>> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>>>
>>> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>>>
>>>>
>>>>
>>>> Tony Hosking wrote:
>>>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> I don't follow the last part of this argument. If we follow the first
>>>> principle, we would just use trampolines, since they are the same
>>>> mechanism the C compiler uses. And the only place they are not possible
>>>> are places where they won't work for C either (e.g., a target where there
>>>> is no place to construct code at runtime and have it be executable).
>>>> The mere fact that we "also build closures" is not a necessity, just
>>>> the reflection of the design decision to use the closure mechanism
>>>> instead of trampolines.
>>>>
>>>> OTHO, despite all the positive things I have said here and in another post
>>>> about trampolines, I don't favor using them, because they would make m3gdb
>>>> support a lot more difficult. m3gdb needs to be able to both read and
>>>> construct closures/trampolines, whichever. Closures are almost target-
>>>> independent, except for the native word size, which is already easily
>>>> available to m3gdb. Trampolines are going to be different for every
>>>> instruction set, and the ones constructed by compiled code, at least,
>>>> could even change with compiler version. m3gdb would need a _lot_ of
>>>> highly target-dependent code to handle them.
>>>>
>>>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>>>
>>>>>> Can any of this be removed?
>>>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>>>> generally a considered the responsibility of optimizers.
>>>>>>
>>>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>>>> Maybe I'll try without.
>>>>>>
>>>>>>
>>>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>>>
>>>>>>
>>>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>>> + m3-util.c */
>>>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>>>> +
>>>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>>>> be adding fields as necessary.
>>>>>> We also build the DECL that represents this frame in the function. */
>>>>>> @@ -209,7 +224,8 @@
>>>>>> free (name);
>>>>>> info->frame_type = type;
>>>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>>>> + info->frame_decl
>>>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>>>> /* ??? Always make it addressable for now, since it is meant to
>>>>>> be pointed to by the static chain pointer. This pessimizes
>>>>>> @@ -218,6 +234,8 @@
>>>>>> reachable, but the true pessimization is to create the non-
>>>>>> local frame structure in the first place. */
>>>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>>>> + /* m3gdb needs to know about this variable. */
>>>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>>>> return type;
>>>>>> }
>>>>>> @@ -290,6 +308,10 @@
>>>>>> return *slot;
>>>>>> }
>>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>>> + m3_util.c */
>>>>>> +static const char * static_link_var_name = "_static_link_var";
>>>>>> +
>>>>>> /* Build or return the variable that holds the static chain within
>>>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>>>> @@ -310,9 +332,14 @@
>>>>>> Note also that it's represented as a parameter. This is more
>>>>>> close to the truth, since the initial value does come from
>>>>>> the caller. */
>>>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>>>> + decl = build_decl
>>>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>>>> DECL_ARTIFICIAL (decl) = 1;
>>>>>> - DECL_IGNORED_P (decl) = 1;
>>>>>> +
>>>>>> + /* m3gdb needs to know about this variable. */
>>>>>> + DECL_IGNORED_P (decl) = 0;
>>>>>> +
>>>>>> TREE_USED (decl) = 1;
>>>>>> DECL_CONTEXT (decl) = info->context;
>>>>>> DECL_ARG_TYPE (decl) = type;
>>>>>> @@ -326,7 +353,11 @@
>>>>>> return decl;
>>>>>> }
>>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>>> + m3_util.c */
>>>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>>>> +
>>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>>>> multiple nesting levels. */
>>>>>> @@ -339,10 +370,12 @@
>>>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>>>> field = make_node (FIELD_DECL);
>>>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>>>> TREE_TYPE (field) = type;
>>>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>>>> + /* m3gdb should know about this field. */
>>>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>>>> @@ -465,7 +498,7 @@
>>>>>> return *slot;
>>>>>> }
>>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>>>> rtl middle-end as dynamic stack space is allocated. */
>>>>>> @@ -1620,6 +1653,9 @@
>>>>>> switch (TREE_CODE (t))
>>>>>> {
>>>>>> case ADDR_EXPR:
>>>>>> + if (TREE_STATIC (t))
>>>>>> + break;
>>>>>> +
>>>>>> /* Build
>>>>>> T.1 = &CHAIN->tramp;
>>>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>>>> @@ -1714,6 +1750,22 @@
>>>>>> }
>>>>>> break;
>>>>>> + case STATIC_CHAIN_EXPR:
>>>>>> + decl = TREE_OPERAND (t, 0);
>>>>>> + target_context = decl_function_context (decl);
>>>>>> + if (target_context)
>>>>>> + {
>>>>>> + if (info->context == target_context)
>>>>>> + {
>>>>>> + /* Make sure frame_decl gets created. */
>>>>>> + (void) get_frame_type (info);
>>>>>> + }
>>>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>>>> + }
>>>>>> + else
>>>>>> + *tp = null_pointer_node;
>>>>>> + break;
>>>>>> +
>>>>>> case RETURN_EXPR:
>>>>>> case GIMPLE_MODIFY_STMT:
>>>>>> case WITH_SIZE_EXPR:
>>>>>> @@ -1768,13 +1820,22 @@
>>>>>> return NULL_TREE;
>>>>>> }
>>>>>> +static bool
>>>>>> +debug_static_links (void)
>>>>>> +{ return
>>>>>> + write_symbols != NO_DEBUG
>>>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>>>> +
>>>>>> +} /* debug_static_links */
>>>>>> +
>>>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>>>> trampolines and call expressions. On the way back up, determine if
>>>>>> a nested function actually uses its static chain; if not, remember that. */
>>>>>> static void
>>>>>> convert_all_function_calls (struct nesting_info *root)
>>>>>> -{
>>>>>> +{
>>>>>> do
>>>>>> {
>>>>>> if (root->inner)
>>>>>> @@ -1784,7 +1845,10 @@
>>>>>> walk_function (convert_call_expr, root);
>>>>>> /* If the function does not use a static chain, then remember that. */
>>>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>>>> +/* REMOVE ME: */
>>>>>> + /* && !debug_static_links () */
>>>>>> + )
>>>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>>>> else
>>>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>>>> @@ -1806,6 +1870,21 @@
>>>>>> tree context = root->context;
>>>>>> struct function *sf;
>>>>>> +/* REMOVEME: */
>>>>>> + /* If this is a nested function and we are supporting debugging via
>>>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>>>> + chain, even if the programmer's code doesn't use it. */
>>>>>> + if (false && root->outer && debug_static_links () )
>>>>>> + { tree static_chain_decl, temp, stmt;
>>>>>> + /* This is a desperate attempt to get later code generation to
>>>>>> + store the static link. If it works, it'll be a miracle. */
>>>>>> + static_chain_decl = get_chain_decl (root);
>>>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>>>> + append_to_statement_list (stmt, &stmt_list);
>>>>>> + }
>>>>>> +
>>>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>>>> out at this time. */
>>>>>> if (root->frame_type)
>>>>>> @@ -1912,7 +1991,7 @@
>>>>>> proper BIND_EXPR. */
>>>>>> if (root->new_local_var_chain)
>>>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>>>> - false);
>>>>>> + true);
>>>>>> if (root->debug_var_chain)
>>>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>>>> true);
>>>>>>
>>>>>>
>>>>>>
>>>
>
 		 	   		  

From jay.krell at cornell.edu  Thu May 27 14:54:39 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 12:54:39 +0000
Subject: [M3devel] a note on parse.c "GTY" use
Message-ID: <COL101-W792CCA7343DD604609EDCE6EA0@phx.gbl>


I am striving to have one parse.c be portable between gcc 4.5, gcc 4.2, and possibly gcc 4.3.
I already established 4.3/4.2 portability a year or so ago.


The main "indefinitely sticky" motivation is that Apple is only on 4.2 and they have a lot of changes.
? That I wouldn't want to merge.
We should imho, use their code for Darwin platforms, or at least Darwin/arm.
?? Mainline FSF seems to work fine for Darwin/ppc/x86 so I'm not advocating change there.



"indefinitely sticky" meaning, not really indefinite, but we aren't in control.
Presumably they'll move up to a newer version but I have no idea when.



Granted, Modula-3/iphone/pod/pad is seemingly nowhere.
A year or so ago I ran cm3 on my iPhone, got the usual "unable to find cm3.cfg", which is
exactly what you want to see when all you have is cm3 and no config files or source, and got distracted after that :)


An alternate motivation would be if we want to more easily move between 4.3 and 4.5.
This one we are more control of. If 4.5 has a few problems on a few platforms, we can
decide to debug and fix, or use 4.3 selectively.
I don't forsee problems major here though.


"Much ado about not much" -- more background than conclusion:


Gcc has some internal garbage collector. You have to annotate your code a bit for it.

In gcc 4.2/4.3 you say:

struct foo GTY()) { int field; } and such


In 4.5 you say:
struct  GTY()) foo { int field; } and such


The thing that scans your code I don't think knows much C.
I wasn't not able use #ifdef to guide it to varying versions.


Therefore, I've isolated 4.3 vs. 4.5-specific uses of GTY to their own files.
It's just a few lines.
But it is not how you would structure the code if not for this goal of working with multiple versions.


Generally otherwise I'll use #ifdef and have src/m3makefile #define whatever.
?Possibly prepending to parse.c, yucky, but oh well.
A read only source tree is ideal, granted, but I do what I can..


GTY is presumably "garbabe collected type" or such.



?- Jay
 		 	   		  

From jay.krell at cornell.edu  Thu May 27 15:07:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 27 May 2010 13:07:10 +0000
Subject: [M3devel] a note on parse.c "GTY" use
In-Reply-To: <COL101-W792CCA7343DD604609EDCE6EA0@phx.gbl>
References: <COL101-W792CCA7343DD604609EDCE6EA0@phx.gbl>
Message-ID: <COL101-W3071349CB8D692DC65B62FE6EA0@phx.gbl>


Hm. Alternatively we could possibly use the data C types...

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 27 May 2010 12:54:39 +0000
> Subject: [M3devel] a note on parse.c "GTY" use
>
>
> I am striving to have one parse.c be portable between gcc 4.5, gcc 4.2, and possibly gcc 4.3.
> I already established 4.3/4.2 portability a year or so ago.
>
>
> The main "indefinitely sticky" motivation is that Apple is only on 4.2 and they have a lot of changes.
>   That I wouldn't want to merge.
> We should imho, use their code for Darwin platforms, or at least Darwin/arm.
>    Mainline FSF seems to work fine for Darwin/ppc/x86 so I'm not advocating change there.
>
>
>
> "indefinitely sticky" meaning, not really indefinite, but we aren't in control.
> Presumably they'll move up to a newer version but I have no idea when.
>
>
>
> Granted, Modula-3/iphone/pod/pad is seemingly nowhere.
> A year or so ago I ran cm3 on my iPhone, got the usual "unable to find cm3.cfg", which is
> exactly what you want to see when all you have is cm3 and no config files or source, and got distracted after that :)
>
>
> An alternate motivation would be if we want to more easily move between 4.3 and 4.5.
> This one we are more control of. If 4.5 has a few problems on a few platforms, we can
> decide to debug and fix, or use 4.3 selectively.
> I don't forsee problems major here though.
>
>
> "Much ado about not much" -- more background than conclusion:
>
>
> Gcc has some internal garbage collector. You have to annotate your code a bit for it.
>
> In gcc 4.2/4.3 you say:
>
> struct foo GTY()) { int field; } and such
>
>
> In 4.5 you say:
> struct GTY()) foo { int field; } and such
>
>
> The thing that scans your code I don't think knows much C.
> I wasn't not able use #ifdef to guide it to varying versions.
>
>
> Therefore, I've isolated 4.3 vs. 4.5-specific uses of GTY to their own files.
> It's just a few lines.
> But it is not how you would structure the code if not for this goal of working with multiple versions.
>
>
> Generally otherwise I'll use #ifdef and have src/m3makefile #define whatever.
>  Possibly prepending to parse.c, yucky, but oh well.
> A read only source tree is ideal, granted, but I do what I can..
>
>
> GTY is presumably "garbabe collected type" or such.
>
>
>
>  - Jay
>
 		 	   		  

From rodney_bates at lcwb.coop  Fri May 28 02:50:51 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 27 May 2010 19:50:51 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
References: <COL101-W3218D31E10B50EEED61B1AE6E90@phx.gbl>,
	<422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<4BFDAB5A.6000304@lcwb.coop>,
	<D9A4A61A-2DF9-4C98-B98E-B29D40326CD5@cs.purdue.edu>
	<col101-w143C043CD005DB6739F07CE6EA0@phx.gbl>
Message-ID: <4BFF136B.7020609@lcwb.coop>



Jay K wrote:
> I also disfavor using gcc trampolines, for the same reason, they require executable stack, which is either unavailable, or probably quite slow (having to call mprotect).
>  
>  
> I had forgotten about them, and your reminding me helps me realize why we have to hack gcc a bit.
>   Because it has a similar but inferior mechanism.
>  
>  
> One wonders about Ada though -- does it supported nested functions?
>   I noticed it bears a striking resembles to Pascal/Modula-3. :)

Ada does have nested procedures, but it does not have variables or parameters
of procedure type at all, and it is these that need a closure/trampoline
mechanism, to hold a pointer to the "environment"  of the runtime procedure
value.

Actually, Ada has a form of procedure parameters, but they are
"generic" parameters, which means "instantiation" (i.e., supplying
the actual procedure parameter) is done statically.  This pretty
much always means the program unit with the procedure parameter
is copied at compile time and modified accordingly.

>  
> And uses the same not great trampoline mechanism?
>  
>  
> If they could be moved to an "executable heap", and be made very debuggable, then I'd favor them.
> Those are two very big ifs.
>  
>  
> Why does m3gdb have to read trampolines? It has to extract a parameter from inside their code?

Yes,  The environment (address of the activation record) is in the closure.  If we used trampolines,
it would be in the trampoline instead.  m3gdb has to read these when an m3gdb expression contains
a call on a parameter of procedure type, to correctly execute the call.  It has to construct a
closure (or, again, it would be a trampoline, if we used them instead) to execute a call that
contains a nested procedure as an actual parameter.

> Ah.
> We could probably..if we really ever get here..which isn't all that likely, we could probably endeavor to format them like so:
>  
>                              -- pointer to function --
>                              -- parameter/static chain whatever --

                                   ^ For a single function, there can be many values of this.  Since this scheme
puts it right before the code of the nested procedure, there could only be one value of it.  Every different
parameter (to some other procedure, usually) can have a different environment.  So this won't work.

>  trampoline points here =>   -- start of code --
>                              -- target dependent position independent not very optimized
>                              -- *constant* hand crafted code that fetchs the data from just before itself
>  
>  
> Would that address the m3gdb problem?
>  Putting the data at fixed negative offsets from the trampoline code?
>  Presumably putting it at fixed positive offsets is the problem -- you'd either round up the trampoline size
>   to try to account for any target, of m3gdb would have to know where in the instruction stream per-target the data is written. Fixed negative offsets seem much better.
>  
>  
> Granted, crafting that code would be.. fun. :)
> Actually it would just be a call to a helper routine and the helper routine would fetch the return address and go from there..still gnarly.
>  
>  
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:33:52 -0400
>> To: rodney_bates at lcwb.coop
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> The trampoline mechanism is broken on many platforms because they disable executable stacks. I strongly favour retaining the current mechanisms.
>>
>> On 26 May 2010, at 19:14, Rodney M. Bates wrote:
>>
>>>
>>> Tony Hosking wrote:
>>>> We should endeavour to use the same functionality that the C compiler uses for its own nested functions, whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>> I don't follow the last part of this argument. If we follow the first
>>> principle, we would just use trampolines, since they are the same
>>> mechanism the C compiler uses. And the only place they are not possible
>>> are places where they won't work for C either (e.g., a target where there
>>> is no place to construct code at runtime and have it be executable).
>>> The mere fact that we "also build closures" is not a necessity, just
>>> the reflection of the design decision to use the closure mechanism
>>> instead of trampolines.
>>>
>>> OTHO, despite all the positive things I have said here and in another post
>>> about trampolines, I don't favor using them, because they would make m3gdb
>>> support a lot more difficult. m3gdb needs to be able to both read and
>>> construct closures/trampolines, whichever. Closures are almost target-
>>> independent, except for the native word size, which is already easily
>>> available to m3gdb. Trampolines are going to be different for every
>>> instruction set, and the ones constructed by compiled code, at least,
>>> could even change with compiler version. m3gdb would need a _lot_ of
>>> highly target-dependent code to handle them.
>>>
>>>> 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 26 May 2010, at 02:05, Jay K wrote:
>>>>> Can any of this be removed?
>>>>> Can we really not just use "unfold-nested-procs" like NT386?
>>>>> We'd just lose a little bit of optimization, in rare cases, stop paying a bad cost/benefit ratio?
>>>>> Part of this is actually *deoptimization*. If the compiler decides the values aren't used, then it should
>>>>> be allowed to remove them. That is normal. Wanting to unused stuff in the debugger isn't
>>>>> generally a considered the responsibility of optimizers.
>>>>>
>>>>> Therefore -- we could "unfold", remove our diffs, and gain some optimization and some deoptimization.
>>>>> Maybe I'll try without.
>>>>>
>>>>>
>>>>> diff -ur /src/orig/gcc-4.3.0/gcc/tree-nested.c /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c
>>>>> --- /src/orig/gcc-4.3.0/gcc/tree-nested.c 2008-02-15 09:36:43.000000000 -0800
>>>>> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-nested.c 2010-05-09 22:27:58.000000000 -0700
>>>>>
>>>>>
>>>>> -/* Build or return the RECORD_TYPE that describes the frame state that is
>>>>> - shared between INFO->CONTEXT and its nested functions. This record will
>>>>> - not be complete until finalize_nesting_tree; up until that point we'll
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3-util.c */
>>>>> +static const char * nonlocal_var_rec_name = "_nonlocal_var_rec";
>>>>> +
>>>>> +/* Build or return the RECORD_TYPE that describes the non-local frame struct
>>>>> + that is shared between INFO->CONTEXT and its nested functions. This record
>>>>> + will not be complete until finalize_nesting_tree; up until that point we'll
>>>>> be adding fields as necessary.
>>>>> We also build the DECL that represents this frame in the function. */
>>>>> @@ -209,7 +224,8 @@
>>>>> free (name);
>>>>> info->frame_type = type;
>>>>> - info->frame_decl = create_tmp_var_for (info, type, "FRAME");
>>>>> + info->frame_decl
>>>>> + = create_tmp_var_for (info, type, nonlocal_var_rec_name);
>>>>> /* ??? Always make it addressable for now, since it is meant to
>>>>> be pointed to by the static chain pointer. This pessimizes
>>>>> @@ -218,6 +234,8 @@
>>>>> reachable, but the true pessimization is to create the non-
>>>>> local frame structure in the first place. */
>>>>> TREE_ADDRESSABLE (info->frame_decl) = 1;
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (info->frame_decl) = 0; }
>>>>> return type;
>>>>> }
>>>>> @@ -290,6 +308,10 @@
>>>>> return *slot;
>>>>> }
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_var_name = "_static_link_var";
>>>>> +
>>>>> /* Build or return the variable that holds the static chain within
>>>>> INFO->CONTEXT. This variable may only be used within INFO->CONTEXT. */
>>>>> @@ -310,9 +332,14 @@
>>>>> Note also that it's represented as a parameter. This is more
>>>>> close to the truth, since the initial value does come from
>>>>> the caller. */
>>>>> - decl = build_decl (PARM_DECL, create_tmp_var_name ("CHAIN"), type);
>>>>> + decl = build_decl
>>>>> + (PARM_DECL, get_identifier (static_link_var_name), type);
>>>>> + TREE_CHAIN (decl) = NULL; /* Possibly redundant, but dbxout needs it. */
>>>>> DECL_ARTIFICIAL (decl) = 1;
>>>>> - DECL_IGNORED_P (decl) = 1;
>>>>> +
>>>>> + /* m3gdb needs to know about this variable. */
>>>>> + DECL_IGNORED_P (decl) = 0;
>>>>> +
>>>>> TREE_USED (decl) = 1;
>>>>> DECL_CONTEXT (decl) = info->context;
>>>>> DECL_ARG_TYPE (decl) = type;
>>>>> @@ -326,7 +353,11 @@
>>>>> return decl;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* This must agree with the string defined by the same name in m3gdb, file
>>>>> + m3_util.c */
>>>>> +static const char * static_link_copy_field_name = "_static_link_copy_field";
>>>>> +
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the static chain for INFO->CONTEXT. This is the way to walk back up
>>>>> multiple nesting levels. */
>>>>> @@ -339,10 +370,12 @@
>>>>> tree type = build_pointer_type (get_frame_type (info->outer));
>>>>> field = make_node (FIELD_DECL);
>>>>> - DECL_NAME (field) = get_identifier ("__chain");
>>>>> + DECL_NAME (field) = get_identifier (static_link_copy_field_name);
>>>>> TREE_TYPE (field) = type;
>>>>> DECL_ALIGN (field) = TYPE_ALIGN (type);
>>>>> DECL_NONADDRESSABLE_P (field) = 1;
>>>>> + /* m3gdb should know about this field. */
>>>>> + DECL_IGNORED_P (field) = 0; insert_field_into_struct (get_frame_type (info), field);
>>>>> @@ -465,7 +498,7 @@
>>>>> return *slot;
>>>>> }
>>>>> -/* Build or return the field within the non-local frame state that holds
>>>>> +/* Build or return the field within the non-local frame struct that holds
>>>>> the non-local goto "jmp_buf". The buffer itself is maintained by the
>>>>> rtl middle-end as dynamic stack space is allocated. */
>>>>> @@ -1620,6 +1653,9 @@
>>>>> switch (TREE_CODE (t))
>>>>> {
>>>>> case ADDR_EXPR:
>>>>> + if (TREE_STATIC (t))
>>>>> + break;
>>>>> +
>>>>> /* Build
>>>>> T.1 = &CHAIN->tramp;
>>>>> T.2 = __builtin_adjust_trampoline (T.1);
>>>>> @@ -1714,6 +1750,22 @@
>>>>> }
>>>>> break;
>>>>> + case STATIC_CHAIN_EXPR:
>>>>> + decl = TREE_OPERAND (t, 0);
>>>>> + target_context = decl_function_context (decl);
>>>>> + if (target_context)
>>>>> + {
>>>>> + if (info->context == target_context)
>>>>> + {
>>>>> + /* Make sure frame_decl gets created. */
>>>>> + (void) get_frame_type (info);
>>>>> + }
>>>>> + *tp = get_static_chain (info, target_context, &wi->tsi);
>>>>> + }
>>>>> + else
>>>>> + *tp = null_pointer_node;
>>>>> + break;
>>>>> +
>>>>> case RETURN_EXPR:
>>>>> case GIMPLE_MODIFY_STMT:
>>>>> case WITH_SIZE_EXPR:
>>>>> @@ -1768,13 +1820,22 @@
>>>>> return NULL_TREE;
>>>>> }
>>>>> +static bool
>>>>> +debug_static_links (void)
>>>>> +{ return
>>>>> + write_symbols != NO_DEBUG
>>>>> + && debug_info_level != DINFO_LEVEL_NONE
>>>>> + && debug_info_level != DINFO_LEVEL_TERSE;
>>>>> +
>>>>> +} /* debug_static_links */
>>>>> +
>>>>> /* Walk the nesting tree starting with ROOT, depth first. Convert all
>>>>> trampolines and call expressions. On the way back up, determine if
>>>>> a nested function actually uses its static chain; if not, remember that. */
>>>>> static void
>>>>> convert_all_function_calls (struct nesting_info *root)
>>>>> -{
>>>>> +{
>>>>> do
>>>>> {
>>>>> if (root->inner)
>>>>> @@ -1784,7 +1845,10 @@
>>>>> walk_function (convert_call_expr, root);
>>>>> /* If the function does not use a static chain, then remember that. */
>>>>> - if (root->outer && !root->chain_decl && !root->chain_field)
>>>>> + if (root->outer && !root->chain_decl && !root->chain_field
>>>>> +/* REMOVE ME: */
>>>>> + /* && !debug_static_links () */
>>>>> + )
>>>>> DECL_NO_STATIC_CHAIN (root->context) = 1;
>>>>> else
>>>>> gcc_assert (!DECL_NO_STATIC_CHAIN (root->context));
>>>>> @@ -1806,6 +1870,21 @@
>>>>> tree context = root->context;
>>>>> struct function *sf;
>>>>> +/* REMOVEME: */
>>>>> + /* If this is a nested function and we are supporting debugging via
>>>>> + m3gdb, we always need a chain_decl, so m3gdb can find the static
>>>>> + chain, even if the programmer's code doesn't use it. */
>>>>> + if (false && root->outer && debug_static_links () )
>>>>> + { tree static_chain_decl, temp, stmt;
>>>>> + /* This is a desperate attempt to get later code generation to
>>>>> + store the static link. If it works, it'll be a miracle. */
>>>>> + static_chain_decl = get_chain_decl (root);
>>>>> + stmt = build_addr (static_chain_decl, root->context);
>>>>> + temp = create_tmp_var_for (root, TREE_TYPE (static_chain_decl), NULL);
>>>>> + stmt = build_gimple_modify_stmt (temp, static_chain_decl);
>>>>> + append_to_statement_list (stmt, &stmt_list);
>>>>> + }
>>>>> +
>>>>> /* If we created a non-local frame type or decl, we need to lay them
>>>>> out at this time. */
>>>>> if (root->frame_type)
>>>>> @@ -1912,7 +1991,7 @@
>>>>> proper BIND_EXPR. */
>>>>> if (root->new_local_var_chain)
>>>>> declare_vars (root->new_local_var_chain, DECL_SAVED_TREE (root->context),
>>>>> - false);
>>>>> + true);
>>>>> if (root->debug_var_chain)
>>>>> declare_vars (root->debug_var_chain, DECL_SAVED_TREE (root->context),
>>>>> true);
>>>>>
>>>>>
>>>>>
>> 		 	   		  


From rodney_bates at lcwb.coop  Fri May 28 03:01:02 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 27 May 2010 20:01:02 -0500
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>
References: <COL101-W37C4A524E851D92EEAB220E6E90@phx.gbl>, ,
	<4BFDA293.9080503@lcwb.coop>,
	<COL101-W34DE705350D2CFFBFC675BE6E90@phx.gbl>,
	<665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
	<COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>
Message-ID: <4BFF15CE.7060908@lcwb.coop>



Jay K wrote:
> Shouldn't gcc be able to optimize about as well any such transform?
>   Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
>  
> Anyway, ok.
>  
> There's stuff I have to figure out and understand here either way.
>  
> Like, does the the static chain "flow" through non-nested calls?

The static chain flows through a series of activation records of calls
on progressively more shallowly nested procedures, until the last link
in the chain leads to an activation of a non-nested procedure.  Here the
static chain ends.

Conceptually, it would be convenient and consistent to think of this non-nested
procedure as having one more static link pointing to an area where all global
variables are stored, but in reality, almost no runtime addressing model does this.
Since globals have whole-program lifetime and always exactly one instance,
it is better to address them in some other way.

Note the static chain is needed for nested procedures even if there
are no procedure variables or parameters.  (e.g. Ada).

>  
>  - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Thu, 27 May 2010 05:27:56 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>>
>>
>>
>> Argh!!!!!
>> No! We don't want to do work in the front-end to get rid of nesting.
>> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>>
>>
>>
>>
>> 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 26 May 2010, at 18:53, Jay K wrote:
>>
>>
>> Rodney, When you get back to it, can you just dig it out of history?
>>
>>
>> I still think we should try to avoid gcc's nested function functionality.
>>
>>
>> Where you use the static chain, not using the nested function functionality should
>> "automatically" be debuggable -- "automatic" as in, once the work is done
>> in the frontend to transform out nesting.
>>
>>
>> "debuggable" as in, you could follow the links yourself in the debugger.
>> The debugger need not search lexically nested functions that have function
>> calls dividing them.
>>
>>
>> ?
>>
>>
>> There's stuff I still need to understand better -- particularly the affect of nested functions
>> on non-nested functions. Is there *always* an extra parameter to *all* functions?
>> It appears so.
>> And I haven't figured out how to merge with 4.5 what I think achieves that.
>>
>>
>> Maybe a good test of test cases here?
>>
>>
>>
>> - Jay
>>
>>
>> ----------------------------------------
>> Date: Wed, 26 May 2010 17:37:07 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] dbxout_static_chain_decl?
>>
>> I left it in because it is a work in progress. I *really* want to get it to
>> work, and I don't what to have to reinvent what is already there when I get
>> to it. I use nested procedures extensively in certain situations, and good
>> debugger support of them is important to me. It all works fine on older code
>> generators than the gcc that added tree-nested.c.
>>
>> Jay K wrote:
>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>> Does it work?
>> Does it accomplish anything?
>> Can I remove it and its calls?
>>
>> /* Special-purpose function to write stabs for the static_chain_decl.
>> So far, this is not working. m3gdb needs the place in the activation
>> record where the SL is stored. Right now, the SL is not necessarily
>> stored at all, but may just be kept in a register. DECL_RTL and
>> DECL_INCOMING_RTL may both have register expressions. But stabs
>> entries for register variables, of kind N_RSYM, are currently ignored
>> by gdb in dbxread.c, and making it read them could create problems
>> elsewhere, because there can be other variables for which both an
>> N_RSYM and an N_LSYM stabs entry are created.
>> */
>> static int
>> dbxout_static_chain_decl (tree decl)
>>
>> It was added 19 months ago by:
>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>
>> as well, do we need the #if 0 code added then?
>>
>> - Jay
>>
>> 		 	   		  


From rodney_bates at lcwb.coop  Fri May 28 03:13:46 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 27 May 2010 20:13:46 -0500
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>,
	<4BFDACC6.6020600@lcwb.coop>
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>
Message-ID: <4BFF18CA.5070107@lcwb.coop>



Jay K wrote:
> Rodney, It's not a data size optimization. It is a code size optimization.
> Adding the padding is ok.
>  

I guess I am really confused here.  I thought you have been advocating making the
closure marker smaller than the native word size.  I don't see how this would
make closures that are not aligned be aligned.  Even if it did help with
the test of the closure marker, the fetching of the environment pointer and
code pointer would still have the same problem, and they can't be made shorter,
because they need all the bits for their values.

Any way, if you don't like the code that non-aligned closures require, why not
just choose to align them?  It seem so much easier than trying to micro-optimize
the code that solves an ugly problem.

>  
>  
> See Aligned_procedures use in.
> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
>  
> PROCEDURE If_closure (proc: Val;  true, false: Label;  freq: Frequency) =
>   VAR skip := Next_label ();  nope := skip;
>   BEGIN
>     IF (false # No_label) THEN  nope := false; END;
>     IF NOT Target.Aligned_procedures THEN
>       Push (proc);
>       Force ();
>       cg.loophole (Type.Addr, Target.Integer.cg_type);
>       Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
>       cg.and (Target.Integer.cg_type);
>       cg.if_true (Target.Integer.cg_type, nope, Always - freq);
>       SPop (1, "If_closure-unaligned");
>     END;
>     Push (proc);
>     Boost_alignment (Target.Address.align);
>     Force ();
>     cg.load_nil ();
>     cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
>     Push (proc);
>     Boost_alignment (Target.Integer.align);
>     Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
>     Push_int (M3RT.CL_marker_value);
>     IF (true # No_label)
>       THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
>       ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
>     END;
>     Set_label (skip);
>     SPop (2, "If_closure");
>   END If_closure;
>  
>  
> Aligned_procedures would become effectively always true.
> Code would be reduced.
>  
>  
> I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
>  
>  
>  - Jay
> 
> 
> 
> ----------------------------------------
>> Date: Wed, 26 May 2010 18:20:38 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] closure marker
>>
>> After the marker, a closure also has two pointers, one to executable code,
>> and one to an environment of nonlocal variables. These will always have
>> to be aligned to whatever pointers require on the target. So making the
>> marker smaller than a native pointer would then require padding the
>> closure to get the pointers aligned. This uses as much space as just
>> keeping the marker word-sized.
>>
>> And no, I don't think it makes any sense to (on a 64-bit target) start
>> a closure on an odd multiple of 4 bytes, just so you can make the marker
>> smaller while keeping the following pointers word-aligned.
>>
>> Jay K wrote:
>>> A little bit of research done (just searching the web):
>>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>>
>>>
>>> all appear to use a 32bit instruction
>>> presumably aligned but I couldn't confirm for all of them.
>>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>>
>>>
>>> Looks like SH has 16bit instructions.
>>>
>>>
>>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>>> With IA64 the expected exception with size=64bits, count=2.
>>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>>> We can revisit at that time.
>>> And really size=64, count=1 might suffice.
>>>
>>> I'm a little torn.
>>> A 64bit marker is more certain.
>>> Code has been this way forever.
>>> etc.
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>>> Subject: closure marker
>>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>>
>>>>
>>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>>> 64bit systems that care about alignment pay quite a penality imho.
>>>>
>>>>
>>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>>
>>>>
>>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>>
>>>>
>>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>>
>>>>
>>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>>
>>>>
>>>> More general might be
>>>> Target.ClosureElementSize (bits)
>>>> Target.ClosureElementCount
>>>>
>>>>
>>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>>
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>> 		 	   		  


From jay.krell at cornell.edu  Fri May 28 05:42:09 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 28 May 2010 03:42:09 +0000
Subject: [M3devel] closure marker
In-Reply-To: <4BFF18CA.5070107@lcwb.coop>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>, ,
	<4BFDACC6.6020600@lcwb.coop>,
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>,
	<4BFF18CA.5070107@lcwb.coop>
Message-ID: <COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>


What I'm describing is keep the closure the same -- integer -1, integer function pointer, integer chain.
But only read 4 bytes when checking for the -1.
Closures are always integer-aligned, but function pointers are not generally.
The code to check if it is a closure would just read 4 bytes and compare to -1, not check the alignment and then read integer-bytes.


Besides the micro-optimization, it *almost* eliminates target-specific code.
? Every time I ported to a system that cares about alignment I wasted time on this.
? Partly that was just because I didn't know about it. Now I know. Future ports easier.

The problem I think is that IA64 works neither with this scheme nor the existing scheme. Not sure.
? Seems more clear IA64 should have 128bit marker. But maybe 64bits are ok.
? If the bundle format is in the first 64 bits, not sure, and given that all bits 1 is an invalid bundle, then...
And possibly SH where code isn't necessarily 4-aligned. Not sure.

?- Jay

----------------------------------------
> Date: Thu, 27 May 2010 20:13:46 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
>
>
> Jay K wrote:
>> Rodney, It's not a data size optimization. It is a code size optimization.
>> Adding the padding is ok.
>>
>
> I guess I am really confused here. I thought you have been advocating making the
> closure marker smaller than the native word size. I don't see how this would
> make closures that are not aligned be aligned. Even if it did help with
> the test of the closure marker, the fetching of the environment pointer and
> code pointer would still have the same problem, and they can't be made shorter,
> because they need all the bits for their values.
>
> Any way, if you don't like the code that non-aligned closures require, why not
> just choose to align them? It seem so much easier than trying to micro-optimize
> the code that solves an ugly problem.
>
>>
>>
>> See Aligned_procedures use in.
>> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
>>
>> PROCEDURE If_closure (proc: Val; true, false: Label; freq: Frequency) =
>> VAR skip := Next_label (); nope := skip;
>> BEGIN
>> IF (false # No_label) THEN nope := false; END;
>> IF NOT Target.Aligned_procedures THEN
>> Push (proc);
>> Force ();
>> cg.loophole (Type.Addr, Target.Integer.cg_type);
>> Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
>> cg.and (Target.Integer.cg_type);
>> cg.if_true (Target.Integer.cg_type, nope, Always - freq);
>> SPop (1, "If_closure-unaligned");
>> END;
>> Push (proc);
>> Boost_alignment (Target.Address.align);
>> Force ();
>> cg.load_nil ();
>> cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
>> Push (proc);
>> Boost_alignment (Target.Integer.align);
>> Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
>> Push_int (M3RT.CL_marker_value);
>> IF (true # No_label)
>> THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
>> ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
>> END;
>> Set_label (skip);
>> SPop (2, "If_closure");
>> END If_closure;
>>
>>
>> Aligned_procedures would become effectively always true.
>> Code would be reduced.
>>
>>
>> I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
>>
>>
>> - Jay
>>
>>
>>
>> ----------------------------------------
>>> Date: Wed, 26 May 2010 18:20:38 -0500
>>> From: rodney_bates at lcwb.coop
>>> To: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] closure marker
>>>
>>> After the marker, a closure also has two pointers, one to executable code,
>>> and one to an environment of nonlocal variables. These will always have
>>> to be aligned to whatever pointers require on the target. So making the
>>> marker smaller than a native pointer would then require padding the
>>> closure to get the pointers aligned. This uses as much space as just
>>> keeping the marker word-sized.
>>>
>>> And no, I don't think it makes any sense to (on a 64-bit target) start
>>> a closure on an odd multiple of 4 bytes, just so you can make the marker
>>> smaller while keeping the following pointers word-aligned.
>>>
>>> Jay K wrote:
>>>> A little bit of research done (just searching the web):
>>>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>>>
>>>>
>>>> all appear to use a 32bit instruction
>>>> presumably aligned but I couldn't confirm for all of them.
>>>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>>>
>>>>
>>>> Looks like SH has 16bit instructions.
>>>>
>>>>
>>>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>>>> With IA64 the expected exception with size=64bits, count=2.
>>>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>>>> We can revisit at that time.
>>>> And really size=64, count=1 might suffice.
>>>>
>>>> I'm a little torn.
>>>> A 64bit marker is more certain.
>>>> Code has been this way forever.
>>>> etc.
>>>>
>>>> - Jay
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>>>> Subject: closure marker
>>>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>>>
>>>>>
>>>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>>>> 64bit systems that care about alignment pay quite a penality imho.
>>>>>
>>>>>
>>>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>>>
>>>>>
>>>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>>>
>>>>>
>>>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>>>
>>>>>
>>>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>>>
>>>>>
>>>>> More general might be
>>>>> Target.ClosureElementSize (bits)
>>>>> Target.ClosureElementCount
>>>>>
>>>>>
>>>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>
 		 	   		  

From hendrik at topoi.pooq.com  Sat May 29 00:04:01 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 28 May 2010 18:04:01 -0400
Subject: [M3devel] dbxout_static_chain_decl?
In-Reply-To: <4BFF15CE.7060908@lcwb.coop>
References: <665072D3-300C-4DE5-B2FE-AC9ACA195AED@cs.purdue.edu>
	<COL101-W2AA9C67C003C3B6F2B76AE6EA0@phx.gbl>
	<4BFF15CE.7060908@lcwb.coop>
Message-ID: <20100528220400.GB4904@topoi.pooq.com>

On Thu, May 27, 2010 at 08:01:02PM -0500, Rodney M. Bates wrote:
>
>
> Jay K wrote:
>> Shouldn't gcc be able to optimize about as well any such transform?
>>   Or would we tend to produce a bunch of structs, take their address, gcc would be strongly inlined to not enregister them and such?
>>  Anyway, ok.
>>  There's stuff I have to figure out and understand here either way.
>>  Like, does the the static chain "flow" through non-nested calls?
>
> The static chain flows through a series of activation records of calls
> on progressively more shallowly nested procedures, until the last link
> in the chain leads to an activation of a non-nested procedure.  Here the
> static chain ends.
>
> Conceptually, it would be convenient and consistent to think of this non-nested
> procedure as having one more static link pointing to an area where all global
> variables are stored, but in reality, almost no runtime addressing model does this.
> Since globals have whole-program lifetime and always exactly one instance,
> it is better to address them in some other way.
>
> Note the static chain is needed for nested procedures even if there
> are no procedure variables or parameters.  (e.g. Ada).

In Algol 68, when it's implemented using static links, the static chain 
doesn't thread *all* the chain of surrounding procedures -- it skips the 
ones that don't define any names used in the inner ones.

This bit of denesting might improve efficiency even in Modula 3, since 
some static chains might end up being shorter.  Whether it's worth the 
effort is another question, of course.

-- hendrik

>>> Argh!!!!!
>>> No! We don't want to do work in the front-end to get rid of nesting.
>>> It is terribly important for performance (e.g., register allocation) that we retain the gcc-based support.
>>>
>>> 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


From hendrik at topoi.pooq.com  Sat May 29 00:07:20 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Fri, 28 May 2010 18:07:20 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <4BFDA90A.3050105@lcwb.coop>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>
	<4BFDA90A.3050105@lcwb.coop>
Message-ID: <20100528220720.GC4904@topoi.pooq.com>

On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>
>
> Jay K wrote:
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>
>>>
>>>
>>> We should endeavour to use the same functionality that the C compiler 
>>> uses for its own nested functions, 
>
> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>
>>
>> Right..for those that don't know..
>>
>>
>> There's no "good" efficient way to implement nested functions.
>> Our implementation is pretty "bad".
>> gcc's implementation is pretty "bad".
>
> I think this is far too critical.  The inefficiencies you see are
> minor.  Certainly no worse than the implementation of dispatching
> methods of objects, something the world is gaga about.

Sufficiently gaga that hardware manufacturers are trying to make it 
really fast.  Things like fetch- and branch- prediction.

We may as well use them if there isn't something better around.

-- hendrik


From jay.krell at cornell.edu  Sat May 29 05:10:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 29 May 2010 03:10:46 +0000
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <20100528220720.GC4904@topoi.pooq.com>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>,
	<20100528220720.GC4904@topoi.pooq.com>
Message-ID: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>


Ok ok let me explain my "real" questions.
 
 
 
 - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
 
 
 
and/or
 
 
 
 
 - Can someone show me how the above translates to C?
   Or Modula-3 with no nested functions.
   Using Modula-3 closures.
   It's not about the syntax, it's about a lower level model.
   Bonus points if you can show me the translation to C-like code with gcc trampolines also.
     That's mainly currently just for curiosity.
 
 
 
and/or
 
 
 
 - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
 
 
 
Like, I need to understand what to do for gcc 4.5.0.
 
 
Some of the tree-nested changes refer to a particular test case.
I'll look there to start.
 
 
 
In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
With a comment that maybe we could do it better.
The context in 4.5 is vastly different now.
The 4.3 changes "completely unmergable".
  I even looked around for somewhere else to put them.
 
 
 
Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
 Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
 
 
 
I'll see if I can get some clues here:
  http://gcc.gnu.org/onlinedocs/gccint/
 
 
:)
 
 
 - Jay




----------------------------------------
> Date: Fri, 28 May 2010 18:07:20 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cc static chain stuff
>
> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>
>>
>> Jay K wrote:
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>
>>>>
>>>>
>>>> We should endeavour to use the same functionality that the C compiler
>>>> uses for its own nested functions,
>>
>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>
>>>
>>> Right..for those that don't know..
>>>
>>>
>>> There's no "good" efficient way to implement nested functions.
>>> Our implementation is pretty "bad".
>>> gcc's implementation is pretty "bad".
>>
>> I think this is far too critical. The inefficiencies you see are
>> minor. Certainly no worse than the implementation of dispatching
>> methods of objects, something the world is gaga about.
>
> Sufficiently gaga that hardware manufacturers are trying to make it
> really fast. Things like fetch- and branch- prediction.
>
> We may as well use them if there isn't something better around.
>
> -- hendrik 		 	   		  

From hendrik at topoi.pooq.com  Sat May 29 10:43:35 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sat, 29 May 2010 04:43:35 -0400
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
References: <20100528220720.GC4904@topoi.pooq.com>
	<COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
Message-ID: <20100529084334.GA10658@topoi.pooq.com>

On Sat, May 29, 2010 at 03:10:46AM +0000, Jay K wrote:
> 
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  

Here's the classic test, in Algol 60:

begin
  real procedure A (k, x1, x2, x3, x4, x5);
  value k; integer k;
  begin
    real procedure B;
    begin k:= k - 1;
          B:= A := A (k, B, x1, x2, x3, x4);
    end;
    if k <= 0 then A:= x4 + x5 else B;
  end;
  outreal (A (10, 1, -1, -1, 1, 0));
end;

reference:

http://en.wikipedia.org/wiki/Man_or_boy_test

See also:

http://www.rosettacode.org/wiki/Man_or_boy_test

This page has a version which simulates closures in C.

-- hendrik


From rodney_bates at lcwb.coop  Sat May 29 22:03:58 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 29 May 2010 15:03:58 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>,
	<20100528220720.GC4904@topoi.pooq.com>
	<COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
Message-ID: <4C01732E.1070609@lcwb.coop>



Jay K wrote:
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  
>  
>  
> and/or
>  
>  
>  
>  
>  - Can someone show me how the above translates to C?
>    Or Modula-3 with no nested functions.
>    Using Modula-3 closures.
>    It's not about the syntax, it's about a lower level model.
>    Bonus points if you can show me the translation to C-like code with gcc trampolines also.
>      That's mainly currently just for curiosity.
>  
>  

I'm about to travel for a week, but maybe I'll give this a shot when I get back.
The problem is, it needs some diagrams, and I'm not fluent in any diagram
editor.  Maybe I can find/recommend a section of a good compiler book on this.

>  
> and/or
>  
>  
>  
>  - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
>  

I believe all that changes to tree-nested.c are mine, and they are only for debugging
support.  If the new tree-nested.c is very different, perhaps I should look at it.

>  
>  
> Like, I need to understand what to do for gcc 4.5.0.
>  
>  
> Some of the tree-nested changes refer to a particular test case.
> I'll look there to start.
>  
>  
>  
> In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
> With a comment that maybe we could do it better.
> The context in 4.5 is vastly different now.
> The 4.3 changes "completely unmergable".
>   I even looked around for somewhere else to put them.
>  
>  
>  
> Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
>  Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
>  
>  
>  
> I'll see if I can get some clues here:
>   http://gcc.gnu.org/onlinedocs/gccint/
>  
>  
> :)
>  
>  
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> Date: Fri, 28 May 2010 18:07:20 -0400
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>>
>>> Jay K wrote:
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>>
>>>>>
>>>>>
>>>>> We should endeavour to use the same functionality that the C compiler
>>>>> uses for its own nested functions,
>>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> Right..for those that don't know..
>>>>
>>>>
>>>> There's no "good" efficient way to implement nested functions.
>>>> Our implementation is pretty "bad".
>>>> gcc's implementation is pretty "bad".
>>> I think this is far too critical. The inefficiencies you see are
>>> minor. Certainly no worse than the implementation of dispatching
>>> methods of objects, something the world is gaga about.
>> Sufficiently gaga that hardware manufacturers are trying to make it
>> really fast. Things like fetch- and branch- prediction.
>>
>> We may as well use them if there isn't something better around.
>>
>> -- hendrik 		 	   		  


From rodney_bates at lcwb.coop  Sat May 29 22:26:11 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 29 May 2010 15:26:11 -0500
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>, ,
	<4BFDACC6.6020600@lcwb.coop>,
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>,
	<4BFF18CA.5070107@lcwb.coop>
	<COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>
Message-ID: <4C017863.2070209@lcwb.coop>

I might be starting to get the picture.  Here's what I think I understand so far:

On the target in question, native word is 64 bits.  Closures are three words, as
usual, all 64-bits and aligned to 64 bits.

The problem comes from the fact that, on this target, the first instruction of
the code of a procedure is not necessarily aligned to 64 bit.

So, when you have a parameter of procedure type, you can't immediately test
whether it points to a closure marker, because if not, it might be a code address
that is not a multiple of 8 bytes, and the attempt to test for the entire 64-bit
marker would suffer an alignment fault.

So, the generated code first tests whether it is a multiple of 8.  If not, that
means it points directly to code.  If so, it still could point to either code or
a closure, but now testing for the marker will not alignment-fault.  And it is
the first test you want to eliminate, right?

And your proposal is to code the marker test to only check a 32-bit half word
for all ones.  This will work for code addresses that are not multiples of 8,
but will still require them to be multiples of 4.

If Target.Aligned_procedures=FALSE really means they are not necessarily 8-byte aligned,
but are necessarily 4-byte aligned, which you need, then I think it is misnamed.
To me, and I think about anybody, I would expect Aligned_procedures=FALSE to mean
they are not aligned at all.  What does it actually mean, for various targets with
various native word sizes?

One approach would be to just make all first instructions of procedures be on
8-byte boundaries.   Aligned_procedures would be TRUE, and the extra code would
not be generated.  Actually, it is hard for me to imagine a modern object module
format and linker the did not ensure this, as I understand that usually, linkers
can selectively remove unreferenced procedures.  This would require the code of
every procedure to be in a separate "section" or whatever, which would then mean
it would be maximally aligned.

Another would be to ascertain that, in the targets where NOT Aligned_procedures,
a byte containing 16_FF can not be the first byte of any opcode.  If so, you
could just have the marker check test only one byte.  (But still build markers
the full length, just for consistency.)

Lacking any of the above, I'd just leave the extra code in there.

Jay K wrote:
> What I'm describing is keep the closure the same -- integer -1, integer function pointer, integer chain.
> But only read 4 bytes when checking for the -1.
> Closures are always integer-aligned, but function pointers are not generally.
> The code to check if it is a closure would just read 4 bytes and compare to -1, not check the alignment and then read integer-bytes.
> 
> 
> Besides the micro-optimization, it *almost* eliminates target-specific code.
>   Every time I ported to a system that cares about alignment I wasted time on this.
>   Partly that was just because I didn't know about it. Now I know. Future ports easier.
> 
> The problem I think is that IA64 works neither with this scheme nor the existing scheme. Not sure.
>   Seems more clear IA64 should have 128bit marker. But maybe 64bits are ok.
>   If the bundle format is in the first 64 bits, not sure, and given that all bits 1 is an invalid bundle, then...
> And possibly SH where code isn't necessarily 4-aligned. Not sure.
> 
>  - Jay
> 
> ----------------------------------------
>> Date: Thu, 27 May 2010 20:13:46 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] closure marker
>>
>>
>>
>> Jay K wrote:
>>> Rodney, It's not a data size optimization. It is a code size optimization.
>>> Adding the padding is ok.
>>>
>> I guess I am really confused here. I thought you have been advocating making the
>> closure marker smaller than the native word size. I don't see how this would
>> make closures that are not aligned be aligned. Even if it did help with
>> the test of the closure marker, the fetching of the environment pointer and
>> code pointer would still have the same problem, and they can't be made shorter,
>> because they need all the bits for their values.
>>
>> Any way, if you don't like the code that non-aligned closures require, why not
>> just choose to align them? It seem so much easier than trying to micro-optimize
>> the code that solves an ugly problem.
>>
>>>
>>> See Aligned_procedures use in.
>>> http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3front/src/misc/CG.m3?rev=1.15.2.4;content-type=text%2Fplain
>>>
>>> PROCEDURE If_closure (proc: Val; true, false: Label; freq: Frequency) =
>>> VAR skip := Next_label (); nope := skip;
>>> BEGIN
>>> IF (false # No_label) THEN nope := false; END;
>>> IF NOT Target.Aligned_procedures THEN
>>> Push (proc);
>>> Force ();
>>> cg.loophole (Type.Addr, Target.Integer.cg_type);
>>> Push_int (TargetMap.CG_Align_bytes[Target.Integer.cg_type] - 1);
>>> cg.and (Target.Integer.cg_type);
>>> cg.if_true (Target.Integer.cg_type, nope, Always - freq);
>>> SPop (1, "If_closure-unaligned");
>>> END;
>>> Push (proc);
>>> Boost_alignment (Target.Address.align);
>>> Force ();
>>> cg.load_nil ();
>>> cg.if_compare (Type.Addr, Cmp.EQ, nope, Always - freq);
>>> Push (proc);
>>> Boost_alignment (Target.Integer.align);
>>> Load_indirect (Target.Integer.cg_type, M3RT.CL_marker, Target.Integer.size);
>>> Push_int (M3RT.CL_marker_value);
>>> IF (true # No_label)
>>> THEN cg.if_compare (Target.Integer.cg_type, Cmp.EQ, true, freq);
>>> ELSE cg.if_compare (Target.Integer.cg_type, Cmp.NE, false, freq);
>>> END;
>>> Set_label (skip);
>>> SPop (2, "If_closure");
>>> END If_closure;
>>>
>>>
>>> Aligned_procedures would become effectively always true.
>>> Code would be reduced.
>>>
>>>
>>> I thought it accessed the value piecemeal, but it just rejects unaligned pointers, which seems less bad.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Date: Wed, 26 May 2010 18:20:38 -0500
>>>> From: rodney_bates at lcwb.coop
>>>> To: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] closure marker
>>>>
>>>> After the marker, a closure also has two pointers, one to executable code,
>>>> and one to an environment of nonlocal variables. These will always have
>>>> to be aligned to whatever pointers require on the target. So making the
>>>> marker smaller than a native pointer would then require padding the
>>>> closure to get the pointers aligned. This uses as much space as just
>>>> keeping the marker word-sized.
>>>>
>>>> And no, I don't think it makes any sense to (on a 64-bit target) start
>>>> a closure on an odd multiple of 4 bytes, just so you can make the marker
>>>> smaller while keeping the following pointers word-aligned.
>>>>
>>>> Jay K wrote:
>>>>> A little bit of research done (just searching the web):
>>>>> Mips, Alpha, PowerPC, HPPA, ARM, SPARC
>>>>>
>>>>>
>>>>> all appear to use a 32bit instruction
>>>>> presumably aligned but I couldn't confirm for all of them.
>>>>> It seems likely that if the processor cares about data alignment, then code will be aligned the same.
>>>>>
>>>>>
>>>>> Looks like SH has 16bit instructions.
>>>>>
>>>>>
>>>>> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
>>>>> With IA64 the expected exception with size=64bits, count=2.
>>>>> It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>>>>> We can revisit at that time.
>>>>> And really size=64, count=1 might suffice.
>>>>>
>>>>> I'm a little torn.
>>>>> A 64bit marker is more certain.
>>>>> Code has been this way forever.
>>>>> etc.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: jay.krell at cornell.edu
>>>>>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>>>>> Subject: closure marker
>>>>>> Date: Wed, 26 May 2010 15:13:38 +0000
>>>>>>
>>>>>>
>>>>>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>>>>>> 64bit systems that care about alignment pay quite a penality imho.
>>>>>>
>>>>>>
>>>>>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>>>>>
>>>>>>
>>>>>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>>>>>
>>>>>>
>>>>>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>>>>> Do they have 4 byte instructions, that are always 4 byte aligned?
>>>>>>
>>>>>>
>>>>>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>>>>>
>>>>>>
>>>>>> More general might be
>>>>>> Target.ClosureElementSize (bits)
>>>>>> Target.ClosureElementCount
>>>>>>
>>>>>>
>>>>>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>>>>>> Whereas most others would have Target.ClosureElementSize = 32, Target.ClosureElementSize = 1.
>>>>>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>  		 	   		  


From rodney_bates at lcwb.coop  Sat May 29 23:17:25 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sat, 29 May 2010 16:17:25 -0500
Subject: [M3devel] m3cc static chain stuff
In-Reply-To: <COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
References: <422C1C66-9CD1-49F0-8A34-2BA04F30F25D@cs.purdue.edu>,
	<COL101-W40CAA4B67306344A39B864E6E90@phx.gbl>,
	<4BFDA90A.3050105@lcwb.coop>,
	<20100528220720.GC4904@topoi.pooq.com>
	<COL101-W6426F72DAE3F0608F7AA90E6EC0@phx.gbl>
Message-ID: <4C018465.7000204@lcwb.coop>

More concerning tree-nested.c:

I am now remembering that there was some inconsistent terminology in
tree-nested.c, calling the same thing by different names, etc, in
comments, and, I think, in some identifiers too.  One thing I did
was clean this up, after having to unravel it for the second time,
not remembering it all from the first time.

If history is any guide, just moving to a newer base gcc will no
doubt break several things in m3gdb, and I'll probably be the logical
one to do most of that part of the patching.


Jay K wrote:
> Ok ok let me explain my "real" questions.
>  
>  
>  
>  - Can someone show me an example (or add a test case) that demonstrates the "full" functionality of nested functions, pointers to them, comparing said pointers for equality, and recursion?
>  
>  
>  
> and/or
>  
>  
>  
>  
>  - Can someone show me how the above translates to C?
>    Or Modula-3 with no nested functions.
>    Using Modula-3 closures.
>    It's not about the syntax, it's about a lower level model.
>    Bonus points if you can show me the translation to C-like code with gcc trampolines also.
>      That's mainly currently just for curiosity.
>  
>  
>  
> and/or
>  
>  
>  
>  - Can someone explain to me all of our changes to tree-nested.c. Not that there is much, granted.
>  
>  
>  
> Like, I need to understand what to do for gcc 4.5.0.
>  
>  
> Some of the tree-nested changes refer to a particular test case.
> I'll look there to start.
>  
>  
>  
> In 4.3 tree-nested we do something, like, visit everything, and change some of the things.
> With a comment that maybe we could do it better.
> The context in 4.5 is vastly different now.
> The 4.3 changes "completely unmergable".
>   I even looked around for somewhere else to put them.
>  
>  
>  
> Ultimately I might succeed through "force of pattern matching", but I'd kinda like to understand as well.
>  Even some of the dbxout.c stuff I don't understand, but it appears to merge easily so probably ok.
>  
>  
>  
> I'll see if I can get some clues here:
>   http://gcc.gnu.org/onlinedocs/gccint/
>  
>  
> :)
>  
>  
>  - Jay
> 
> 
> 
> 
> ----------------------------------------
>> Date: Fri, 28 May 2010 18:07:20 -0400
>> From: hendrik at topoi.pooq.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] m3cc static chain stuff
>>
>> On Wed, May 26, 2010 at 06:04:42PM -0500, Rodney M. Bates wrote:
>>>
>>> Jay K wrote:
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Wed, 26 May 2010 10:28:51 -0400
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] m3cc static chain stuff
>>>>>
>>>>>
>>>>>
>>>>> We should endeavour to use the same functionality that the C compiler
>>>>> uses for its own nested functions,
>>> whereever possible. The only thing is that we also build closures, so the trampoline mechanisms should be avoided.
>>>>
>>>> Right..for those that don't know..
>>>>
>>>>
>>>> There's no "good" efficient way to implement nested functions.
>>>> Our implementation is pretty "bad".
>>>> gcc's implementation is pretty "bad".
>>> I think this is far too critical. The inefficiencies you see are
>>> minor. Certainly no worse than the implementation of dispatching
>>> methods of objects, something the world is gaga about.
>> Sufficiently gaga that hardware manufacturers are trying to make it
>> really fast. Things like fetch- and branch- prediction.
>>
>> We may as well use them if there isn't something better around.
>>
>> -- hendrik 		 	   		  


From jay.krell at cornell.edu  Sun May 30 09:45:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 07:45:38 +0000
Subject: [M3devel] closure marker
In-Reply-To: <4C017863.2070209@lcwb.coop>
References: <COL101-W6133F6F44D36461BCE7E7DE6E90@phx.gbl>,
	, , <4BFDACC6.6020600@lcwb.coop>, ,
	<COL101-W189B7D7ACA82A6CED29515E6E90@phx.gbl>, ,
	<4BFF18CA.5070107@lcwb.coop>,
	<COL101-W13E4D66D17EF453025B487E6EB0@phx.gbl>,
	<4C017863.2070209@lcwb.coop>
Message-ID: <COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>


> On the target in question, native word is 64 bits. Closures are three words, as
> usual, all 64-bits and aligned to 64 bits.

Right.
Though I think for IA64 we might need 128bit marker.
?At least that is the easy conclusion barring deeper understanding.


> The problem comes from the fact that, on this target, the first instruction of
> the code of a procedure is not necessarily aligned to 64 bit.


Right.


> So, when you have a parameter of procedure type, you can't immediately test
> whether it points to a closure marker, because if not, it might be a code address
> that is not a multiple of 8 bytes, and the attempt to test for the entire 64-bit
> marker would suffer an alignment fault.


Right.
I've seen these alignment faults doing several ports.
But now we all know, so maybe not a big deal.


> So, the generated code first tests whether it is a multiple of 8. If not, that
> means it points directly to code. If so, it still could point to either code or
> a closure, but now testing for the marker will not alignment-fault. And it is
> the first test you want to eliminate, right?


Right.


> And your proposal is to code the marker test to only check a 32-bit half word
> for all ones. This will work for code addresses that are not multiples of 8,
> but will still require them to be multiples of 4.


Right.
Admited, initially I forgot about the "rest" of the closure, so didn't
allow for the extra in what I said.


> If Target.Aligned_procedures=FALSE really means they are not necessarily 8-byte aligned,
> but are necessarily 4-byte aligned, which you need, then I think it is misnamed.
> To me, and I think about anybody, I would expect Aligned_procedures=FALSE to mean
> they are not aligned at all. What does it actually mean, for various targets with
> various native word sizes?


Right -- the name is wierd, but hard to come up with another.
It means: can an integer-sized read from a function pointer possibly generate an alignment exception.
Inverted.
For example. on all x86 and AMD64 targets, it is true. Because none of them ever generate
alignment faults (maybe for SSE stuff, irrelevant).


On most/all 32bit targets is also true, because instructions are often guaranteed 4 byte aligned.


?> One approach would be to just make all first instructions of procedures be on
?> 8-byte boundaries.


That might not be trivial.
C code matters too.
It can also be size-wasteful, but often speed-optimizing.


?> Aligned_procedures would be TRUE, and the extra code would
> not be generated. Actually, it is hard for me to imagine a modern object module
> format and linker the did not ensure this, as I understand that usually, linkers
> can selectively remove unreferenced procedures. This would require the code of
> every procedure to be in a separate "section" or whatever, which would then mean
> it would be maximally aligned.


All modern systems (can) remove unused functions.
Surprisingly I don't think this is always/often the default.
In Visual C++ you have to use the -Gy flag to the compiler.
But that doesn't imply anything about alignment.
Maybe you are confusing some concepts?
For example on Win32, executables have "sections".


e.g. .text, .data, .rdata.


By "conceptual reverse engineering", I claim that "sections" exist in order to apply
different page attributes to parts of code/data. That is, read only data and writable
data must be on different pages, if the read onliness is to actually exist and be hardware-enforced.


Therefore, whichever of the two, readonly/writable, comes second, must be page aligned,
in order to not be on the same page as the previous.


On modern systems that have a page attribute "executable", code must also be separate from
read only data.


This does *not* relate to any sort of alignment of functions (except maybe the first function
in an .exe/.dll, maybe).


Sections can also be a crude tool to influence layout and improve locality.
For example the data needed to handle exceptions might be in its own section, in order
to keep it "far away" from everything else, since it is rarely accessed.
Even though it generally just as well be part of read only data.
This way "everything else" is denser and fits on fewer pages.


Size and density are the generally dominant performance factors in most systems.
Touching the disk to page in stuff is among the slowest operations by far, so
reducing size, in order to reduce the number of pages touched, is important.
? Bigger code that is deemed "faster" is rarely preferred.
? Smaller code is also preferred in "embedded" systems.

Anyway..


> Another would be to ascertain that, in the targets where NOT Aligned_procedures,
> a byte containing 16_FF can not be the first byte of any opcode.
> If so, you? could just have the marker check test only one byte. (But still build markers
> the full length, just for consistency.)


No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
I'm not willing to make that bet.
Even the notion of 4 or 8 byte -1 I find tenuous.
You cannot portably/easily guarantee that such bytes aren't valid/existant code.
You must research all the various architecture encodings.
? Granted, we are only talking about function prologues..
The longer the sequence, the statistically less likely it is valid or existant code.
And there is a limit, per-architecture.
Many architectures have fixed length instructions.
On such architectures, going beyond that length does not change the odds of validity,
though does change the odds of existance (if valid). But our hope is really for invalidity,
not mere non-existance.


> Lacking any of the above, I'd just leave the extra code in there.


Yeah, it's not as much as I had thougt.
I was thinking it generated code to read the bytes piecemeal or something.


Again though, my real goal is to try to remove platform-specificity.
Something that can be made true for all architectures with no downside, should be made so,
and the variable removed.


I think even the current scheme maybe invalid for IA64.
We should probably have ClosureMarkerSizeStored and ClosureMarkerSizeChecked.
?


Except for IA64 and possibly SH, ClosureMarkerSizeStored should be sizeof(INTEGER) and ClosureMarkerSizeChecked would be 4.


The nice property there is that, barring existance of IA64 and SH, we would remove the target-specificity entirely,
and m3gdb would be unchanged. IA64 and SH might work, not sure.
I do have two IA64 machines and a Dreamcast, but...


I'd also like to understand what this all might look like with a portable C generating backend.
Clearly, reasonably the generated code might need to be able to say:
?#if WORD_SIZE == 4 
?#if ENDIAN == LITTLE_ENDIAN 


but hopefully not much else.
And maybe not even those. :)


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sun May 30 11:47:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 09:47:21 +0000
Subject: [M3devel] the slightly difficult to merge parts 4.3 vs. 4.5
Message-ID: <COL101-W641326A298A33186042008E6ED0@phx.gbl>


--- /src/orig/gcc-4.3.0/gcc/tree-gimple.c??? 2007-12-13 13:49:09.000000000 -0800
+++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-gimple.c??? 2010-05-09 22:27:56.000000000 -0700
@@ -74,6 +74,7 @@
???? case VECTOR_CST:
???? case OBJ_TYPE_REF:
???? case ASSERT_EXPR:
+??? case STATIC_CHAIN_EXPR:
?????? return true;
?
???? default:


That is in is gimple_formal_tmp_rhs, which no longer exists, but which the various
callers do. One obvious guess is callers should each check for STATIC_CHAIN_EXPR.



tree-nested.c:
+??? case STATIC_CHAIN_EXPR:
+????? decl = TREE_OPERAND (t, 0);
+????? target_context = decl_function_context (decl);
+????? if (target_context)
+??? {
+??? ? if (info->context == target_context)
+??? ??? {
+??? ????? /* Make sure frame_decl gets created.? */
+??? ????? (void) get_frame_type (info);
+??? ??? }
+??? ? *tp = get_static_chain (info, target_context, &wi->tsi);
+??? }
+????? else
+??? *tp = null_pointer_node;
+????? break;
+


That is in convert_call_expr.
Which is now called convert_gimple_call, but which is significantly different.
Hm..I see...there is a new gimple.def, similar to tree.def..

Maybe just have to put STATIC_CHAIN_EXPR in there instead, or
put a form in each.

?- Jay

 		 	   		  

From hendrik at topoi.pooq.com  Sun May 30 08:56:47 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Sun, 30 May 2010 02:56:47 -0400
Subject: [M3devel] closure marker
In-Reply-To: <COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>
References: <4C017863.2070209@lcwb.coop>
	<COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>
Message-ID: <20100530065647.GA21438@topoi.pooq.com>

On Sun, May 30, 2010 at 07:45:38AM +0000, Jay K wrote:
> 
> > On the target in question, native word is 64 bits. Closures are three words, as
> > usual, all 64-bits and aligned to 64 bits.
> 
> Right.
> Though I think for IA64 we might need 128bit marker.
> ?At least that is the easy conclusion barring deeper understanding.
> 
...
...
> 
> 
> Size and density are the generally dominant performance factors in most systems.
> Touching the disk to page in stuff is among the slowest operations by far, so
> reducing size, in order to reduce the number of pages touched, is important.
> ? Bigger code that is deemed "faster" is rarely preferred.
> ? Smaller code is also preferred in "embedded" systems.
> 
...
...> 
> No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
> I'm not willing to make that bet.
> Even the notion of 4 or 8 byte -1 I find tenuous.
> You cannot portably/easily guarantee that such bytes aren't valid/existant code.
> You must research all the various architecture encodings.
> ? Granted, we are only talking about function prologues..
> The longer the sequence, the statistically less likely it is valid or existant code.
> And there is a limit, per-architecture.
> Many architectures have fixed length instructions.
> On such architectures, going beyond that length does not change the odds of validity,
> though does change the odds of existance (if valid). But our hope is really for invalidity,
> not mere non-existance.
> 
...
...
> 
> Again though, my real goal is to try to remove platform-specificity.
> Something that can be made true for all architectures with no downside, should be made so,
> and the variable removed.
> 
> 
> I'd also like to understand what this all might look like with a portable C generating backend.
> Clearly, reasonably the generated code might need to be able to say:
> ?#if WORD_SIZE == 4 
> ?#if ENDIAN == LITTLE_ENDIAN 
> 
> 
> but hopefully not much else.
> And maybe not even those. :)
> 
> 
> ?- Jay
>  		 	   		  
If you can't find a bit pattern that's code on all architectures, 
neither as code address or as instructions, and you insist on being 
completely target-independent, the only solution I see is to make 
procedure addresses into two-word objects.  Instead of using the pointer 
to the code as procedure address, you use the two-word closure as 
procedure address, and copy those two words around as the address of a 
procedure.  For top-level procedures, use NIL as the environment poi 
ter.

I was really surprised when I discovered that Modula 3 didn't do it this 
way.

It's really a trade-off between data size (procedure pointers being 
bigger) and code size (procedure calls should be fast and avoid a lot of 
run-time checks) 

What does gcc use for the addresses of nested procedures?  Does it 
generate code dynamically on the stack or heap to make it fit into one 
word?

Oh.  There's also a compatibility issue.  To what extent are we 
constrained to use the same coding as C for procedure addresses?

-- hendrik


From jay.krell at cornell.edu  Sun May 30 13:45:36 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 11:45:36 +0000
Subject: [M3devel] the slightly difficult to merge parts 4.3 vs. 4.5
In-Reply-To: <COL101-W641326A298A33186042008E6ED0@phx.gbl>
References: <COL101-W641326A298A33186042008E6ED0@phx.gbl>
Message-ID: <COL101-W9FB75D787ADC38A9E21F1E6ED0@phx.gbl>


I'm understanding this a bit more.
The process of converting "generic" trees to "gimple" seems to have changed a bunch.
The set of tree opcodes and gimple opcodes are now completely seperate I believe -- gimple.def is new.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Sun, 30 May 2010 09:47:21 +0000
> Subject: [M3devel] the slightly difficult to merge parts 4.3 vs. 4.5
>
>
> --- /src/orig/gcc-4.3.0/gcc/tree-gimple.c    2007-12-13 13:49:09.000000000 -0800
> +++ /dev2/cm3/m3-sys/m3cc/gcc/gcc/tree-gimple.c    2010-05-09 22:27:56.000000000 -0700
> @@ -74,6 +74,7 @@
>      case VECTOR_CST:
>      case OBJ_TYPE_REF:
>      case ASSERT_EXPR:
> +    case STATIC_CHAIN_EXPR:
>        return true;
>
>      default:
>
>
> That is in is gimple_formal_tmp_rhs, which no longer exists, but which the various
> callers do. One obvious guess is callers should each check for STATIC_CHAIN_EXPR.
>
>
>
> tree-nested.c:
> +    case STATIC_CHAIN_EXPR:
> +      decl = TREE_OPERAND (t, 0);
> +      target_context = decl_function_context (decl);
> +      if (target_context)
> +    {
> +      if (info->context == target_context)
> +        {
> +          /* Make sure frame_decl gets created.  */
> +          (void) get_frame_type (info);
> +        }
> +      *tp = get_static_chain (info, target_context, &wi->tsi);
> +    }
> +      else
> +    *tp = null_pointer_node;
> +      break;
> +
>
>
> That is in convert_call_expr.
> Which is now called convert_gimple_call, but which is significantly different.
> Hm..I see...there is a new gimple.def, similar to tree.def..
>
> Maybe just have to put STATIC_CHAIN_EXPR in there instead, or
> put a form in each.
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Sun May 30 13:44:29 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 11:44:29 +0000
Subject: [M3devel] closure marker
In-Reply-To: <20100530065647.GA21438@topoi.pooq.com>
References: <4C017863.2070209@lcwb.coop>,
	<COL101-W16497E7FAA6D1077C942DE6ED0@phx.gbl>,
	<20100530065647.GA21438@topoi.pooq.com>
Message-ID: <COL101-W29F2F362A57035BBF95F02E6ED0@phx.gbl>


gcc generates code on the stack.
?Which Tony and I both don't like.
? I think you could change it to generate on an executable heap though -- after all, Java and C# do still work.
? And ATL even does this, to get the this pointer to a WindowProc.


We could use a per-target marker if necessary.


We do pass function pointers to C -- window procs, thread entry.
However, we could handled through a little glue code.


As well, we could disallow passing function pointers to <* external *> functions.
Or taking the address of <* external *> functions.


So interesting idea then -- change procedure pointers to be two words, function pointer and static link?
?Too inefficient? Too incompatible? Too big of a change?


Actually toplevel could benefit from non-null static link, for the sake of position independence.
Some C calling conventions do this sort of thing.


?- Jay


----------------------------------------
> Date: Sun, 30 May 2010 02:56:47 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
> On Sun, May 30, 2010 at 07:45:38AM +0000, Jay K wrote:
>>
>>> On the target in question, native word is 64 bits. Closures are three words, as
>>> usual, all 64-bits and aligned to 64 bits.
>>
>> Right.
>> Though I think for IA64 we might need 128bit marker.
>>  At least that is the easy conclusion barring deeper understanding.
>>
> ...
> ...
>>
>>
>> Size and density are the generally dominant performance factors in most systems.
>> Touching the disk to page in stuff is among the slowest operations by far, so
>> reducing size, in order to reduce the number of pages touched, is important.
>>   Bigger code that is deemed "faster" is rarely preferred.
>>   Smaller code is also preferred in "embedded" systems.
>>
> ...
> ...>
>> No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
>> I'm not willing to make that bet.
>> Even the notion of 4 or 8 byte -1 I find tenuous.
>> You cannot portably/easily guarantee that such bytes aren't valid/existant code.
>> You must research all the various architecture encodings.
>>   Granted, we are only talking about function prologues..
>> The longer the sequence, the statistically less likely it is valid or existant code.
>> And there is a limit, per-architecture.
>> Many architectures have fixed length instructions.
>> On such architectures, going beyond that length does not change the odds of validity,
>> though does change the odds of existance (if valid). But our hope is really for invalidity,
>> not mere non-existance.
>>
> ...
> ...
>>
>> Again though, my real goal is to try to remove platform-specificity.
>> Something that can be made true for all architectures with no downside, should be made so,
>> and the variable removed.
>>
>>
>> I'd also like to understand what this all might look like with a portable C generating backend.
>> Clearly, reasonably the generated code might need to be able to say:
>>  #if WORD_SIZE == 4
>>  #if ENDIAN == LITTLE_ENDIAN
>>
>>
>> but hopefully not much else.
>> And maybe not even those. :)
>>
>>
>>  - Jay
>>
> If you can't find a bit pattern that's code on all architectures,
> neither as code address or as instructions, and you insist on being
> completely target-independent, the only solution I see is to make
> procedure addresses into two-word objects. Instead of using the pointer
> to the code as procedure address, you use the two-word closure as
> procedure address, and copy those two words around as the address of a
> procedure. For top-level procedures, use NIL as the environment poi
> ter.
>
> I was really surprised when I discovered that Modula 3 didn't do it this
> way.
>
> It's really a trade-off between data size (procedure pointers being
> bigger) and code size (procedure calls should be fast and avoid a lot of
> run-time checks)
>
> What does gcc use for the addresses of nested procedures? Does it
> generate code dynamically on the stack or heap to make it fit into one
> word?
>
> Oh. There's also a compatibility issue. To what extent are we
> constrained to use the same coding as C for procedure addresses?
>
> -- hendrik
 		 	   		  

From jay.krell at cornell.edu  Sun May 30 20:11:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 30 May 2010 18:11:26 +0000
Subject: [M3devel] optimizer doesn't do much?
Message-ID: <COL101-W38377DF1B65EBB708E2D6FE6ED0@phx.gbl>


This little function:


PROCEDURE CallProcx (p: FinallyProc;? VAR a: RT0.RaiseActivation) RAISES ANY =
? BEGIN
??? p (a);
? END CallProcx;


generates all of this at -O2 and above:


_RTExFrame__CallProcx:
??? pushq??? %rbp
??? movq??? %rsp, %rbp
??? subq??? $32, %rsp
???? movq??? %rdi, -24(%rbp)
??? movq??? %rsi, -32(%rbp)
??? movq??? -24(%rbp), %rax ; why not just use %rdi?
??? movq??? %rax, -8(%rbp)
??? movq??? -8(%rbp), %rax ; why? It just stored it!
??? testq??? %rax, %rax
??? je??? L2 ; huh? Compare to NIL, then then just call it anyway?
??? movq??? -8(%rbp), %rax ; why? Again, it is already there.
??? cmpq??? $-1, (%rax)
??? jne??? L2
??? movq??? -8(%rbp), %rax ; why? Again, it is already there.
??? movq??? 16(%rax), %rax
??? movq??? %rax, -16(%rbp)
??? movq??? -8(%rbp), %rax ; again! yeah %rax got clobbered,
??? ?????????????????????? ; but surely it could be using
??? ?????????????????????? ; a different register?
??? movq??? 8(%rax), %rax
??? movq??? %rax, -8(%rbp)
L2:
??? movq??? -8(%rbp), %rax? ; and again
??? movq??? -32(%rbp), %rdi ; %rsi still has it..
??? movq??? -16(%rbp), %r10
??? call??? *%rax
??? leave
??? ret


it is even worse if you omit RAISES ANY.
RAISES ANY saves it from calling pushframe.
and shouldn't it be calling fault_proc for NIL?


Here is what similar C code gets me:
Is this a fair comparison?


typedef void (*F1)(void* chain, void* activation);

typedef struct {
??? long marker;
??? F1 f1;
??? void* chain;
} Closure_t;


void call_F1(Closure_t* cl, void* activation)
{
??? if (cl->marker == -1)
??????? cl->f1(cl->chain, activation);
??? else
??????? ((F1)cl)(0, activation);
}


_call_F1:
??? pushl??? %ebp
??? movl??? %esp, %ebp
??? movl??? 8(%ebp), %ecx
??? movl??? 12(%ebp), %eax
??? cmpl??? $-1, (%ecx)
??? je??? L7
??? movl??? %eax, 12(%ebp)
??? movl??? $0, 8(%ebp)
??? leave
??? jmp??? *%ecx
??? .align 4,0x90
L7:
??? movl??? 8(%ecx), %eax
??? movl??? %eax, 8(%ebp)
??? movl??? 4(%ecx), %ecx
??? leave
??? jmp??? *%ecx


.err..oops different processor:


_call_F1:
??? pushq??? %rbp
??? cmpq??? $-1, (%rdi)
??? movq??? %rdi, %rax
??? movq??? %rsp, %rbp
??? je??? L7
??? xorl??? %edi, %edi
??? movq??? %rax, %r11
??? leave
??? jmp??? *%r11
L7:
??? movq??? 16(%rdi), %rdi
??? movq??? 8(%rax), %r11
??? leave
??? jmp??? *%r11


I don't always care, at least it works, but it does seem surprisingly bad.


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Mon May 31 02:34:32 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 00:34:32 +0000
Subject: [M3devel] more flailing on STATIC_CHAIN_EXPR
Message-ID: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>


so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
? Not sure the generated code is correct yet, haven't run it.
? I'll keep digging esp. on the existing errors.


However I'm still a bit "confused".


What is the point of STATIC_CHAIN_EXPR?


I still have to try the man/boy example, sorry and thank you.


Back to the question of STATIC_CHAIN_EXPR.


I can see it used in tree-nested.
So it doesn't seem pointless.


However, notice the following:
?gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
?It knows the function is nested. It figures out what references resolve how.
? Locals that are referenced by a nested function are put in a local struct.
? Sometimes by value, sometimes by pointer, depending.
? Non-local references go through the chain, n levels, etc.
? I believe it figures out itself to pass the static link.
? It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.


Now, the parts that I recognize are less automatic:
? static link use can't be optimized away, because it is part of function pointer equality.
? That is what some of our changes to tree-nested are about.
? Furthermore, if it can't be optimized away, it might also be forced to exist in the first place. 
?? Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
? 

The part in 4.5 that says:
DECL_STATIC_CHAIN (decl) = 0;


should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
we can reliably set it in parse.c.


One thing I'm sure I'm missing though is indirect calls.
>From gcc's point of view, indirect calls never? have a static link?
And from ours they always do?
??


This must be key. Direct nested calls need no special support. 
? So a lot will just work.
And all indirect calls need special support, since they might be to a closure.
?


I'll keep trying to understand.


I can get stuff to compile by having m3cg_load_static_link just push nul.
? Feels wrong though. I have to look at the code, but in the RtExFrame example, 
?? it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
?? seems to contain an extra.
When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
wierd behavior like compiler hanging, busy growing arrays very large.


If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
at least to make it go away, else gimplification reasonably complains that it doesn't
know what to do with it.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon May 31 10:26:41 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 31 May 2010 04:26:41 -0400
Subject: [M3devel] more flailing on STATIC_CHAIN_EXPR
In-Reply-To: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>
References: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>
Message-ID: <4521E50B-DF20-467A-B0CC-C5D97D83A42A@cs.purdue.edu>

I suggest you play around with various nested procedure sources and see what code is generated for static chains to understand what is going on.  It has been a long while since I looked at this code and I don't remember all the details.  If I had some time I could probably dredge it up.  But the important thing is that we need to be able to build procedure closures so we need some way to reify the static chain for a procedure.  That's why we need an explicit EXPR.

On 30 May 2010, at 20:34, Jay K wrote:

> 
> so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
>   Not sure the generated code is correct yet, haven't run it.
>   I'll keep digging esp. on the existing errors.
> 
> 
> However I'm still a bit "confused".
> 
> 
> What is the point of STATIC_CHAIN_EXPR?
> 
> 
> I still have to try the man/boy example, sorry and thank you.
> 
> 
> Back to the question of STATIC_CHAIN_EXPR.
> 
> 
> I can see it used in tree-nested.
> So it doesn't seem pointless.
> 
> 
> However, notice the following:
>  gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
>  It knows the function is nested. It figures out what references resolve how.
>   Locals that are referenced by a nested function are put in a local struct.
>   Sometimes by value, sometimes by pointer, depending.
>   Non-local references go through the chain, n levels, etc.
>   I believe it figures out itself to pass the static link.
>   It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.
> 
> 
> Now, the parts that I recognize are less automatic:
>   static link use can't be optimized away, because it is part of function pointer equality.
>   That is what some of our changes to tree-nested are about.
>   Furthermore, if it can't be optimized away, it might also be forced to exist in the first place. 
>    Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
>   
> 
> The part in 4.5 that says:
> DECL_STATIC_CHAIN (decl) = 0;
> 
> 
> should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
> we can reliably set it in parse.c.
> 
> 
> One thing I'm sure I'm missing though is indirect calls.
>> From gcc's point of view, indirect calls never? have a static link?
> And from ours they always do?
> ??
> 
> 
> This must be key. Direct nested calls need no special support. 
>   So a lot will just work.
> And all indirect calls need special support, since they might be to a closure.
> ?
> 
> 
> I'll keep trying to understand.
> 
> 
> I can get stuff to compile by having m3cg_load_static_link just push nul.
>   Feels wrong though. I have to look at the code, but in the RtExFrame example, 
>    it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
>    seems to contain an extra.
> When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
> wierd behavior like compiler hanging, busy growing arrays very large.
> 
> 
> If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
> at least to make it go away, else gimplification reasonably complains that it doesn't
> know what to do with it.
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Mon May 31 10:37:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 08:37:26 +0000
Subject: [M3devel] more flailing on STATIC_CHAIN_EXPR
In-Reply-To: <4521E50B-DF20-467A-B0CC-C5D97D83A42A@cs.purdue.edu>
References: <COL101-W167AAB1156A5DC9F4A4BE1E6EE0@phx.gbl>,
	<4521E50B-DF20-467A-B0CC-C5D97D83A42A@cs.purdue.edu>
Message-ID: <COL101-W9E39A755BF969730EFD1FE6EE0@phx.gbl>


Ah. That little clue does help.

gcc notices which locals are used in nested functions.
gcc puts those (or pointers to them) in a local struct.
We want the address of that struct so we can store it elsewhere, in our closure.
? (gcc would store it in a trampoline.)


I do have try some small samples, and compile with cm3cg -y..

Thanks,
?- Jay

----------------------------------------
> Subject: Re: [M3devel] more flailing on STATIC_CHAIN_EXPR
> From: hosking at cs.purdue.edu
> Date: Mon, 31 May 2010 04:26:41 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I suggest you play around with various nested procedure sources and see what code is generated for static chains to understand what is going on. It has been a long while since I looked at this code and I don't remember all the details. If I had some time I could probably dredge it up. But the important thing is that we need to be able to build procedure closures so we need some way to reify the static chain for a procedure. That's why we need an explicit EXPR.
>
> On 30 May 2010, at 20:34, Jay K wrote:
>
>>
>> so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
>> Not sure the generated code is correct yet, haven't run it.
>> I'll keep digging esp. on the existing errors.
>>
>>
>> However I'm still a bit "confused".
>>
>>
>> What is the point of STATIC_CHAIN_EXPR?
>>
>>
>> I still have to try the man/boy example, sorry and thank you.
>>
>>
>> Back to the question of STATIC_CHAIN_EXPR.
>>
>>
>> I can see it used in tree-nested.
>> So it doesn't seem pointless.
>>
>>
>> However, notice the following:
>> gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
>> It knows the function is nested. It figures out what references resolve how.
>> Locals that are referenced by a nested function are put in a local struct.
>> Sometimes by value, sometimes by pointer, depending.
>> Non-local references go through the chain, n levels, etc.
>> I believe it figures out itself to pass the static link.
>> It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.
>>
>>
>> Now, the parts that I recognize are less automatic:
>> static link use can't be optimized away, because it is part of function pointer equality.
>> That is what some of our changes to tree-nested are about.
>> Furthermore, if it can't be optimized away, it might also be forced to exist in the first place.
>> Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
>>
>>
>> The part in 4.5 that says:
>> DECL_STATIC_CHAIN (decl) = 0;
>>
>>
>> should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
>> we can reliably set it in parse.c.
>>
>>
>> One thing I'm sure I'm missing though is indirect calls.
>>> From gcc's point of view, indirect calls never? have a static link?
>> And from ours they always do?
>> ??
>>
>>
>> This must be key. Direct nested calls need no special support.
>> So a lot will just work.
>> And all indirect calls need special support, since they might be to a closure.
>> ?
>>
>>
>> I'll keep trying to understand.
>>
>>
>> I can get stuff to compile by having m3cg_load_static_link just push nul.
>> Feels wrong though. I have to look at the code, but in the RtExFrame example,
>> it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
>> seems to contain an extra.
>> When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
>> wierd behavior like compiler hanging, busy growing arrays very large.
>>
>>
>> If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
>> at least to make it go away, else gimplification reasonably complains that it doesn't
>> know what to do with it.
>>
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Mon May 31 10:44:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 08:44:27 +0000
Subject: [M3devel] m3cc -enable-checking=all
Message-ID: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>


????? Configure = Configure & " -enable-checking=all"


enables a bunch of extra checks.
That fail.
With the current 4.3 backend.
I'm going to look into some/all of this.


.1079 = D.1078 & 1
../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
word_64

int_64

int_64

D.1101 = D.1100 & 1
../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
word_64

int_64

int_64

D.1121 = D.1120 & 1
../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
word_64


I think this might be one and only one problem.
The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.

Probably positive constants that fit in the signed type of the same size shouldn't fail.

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Mon May 31 11:50:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 09:50:59 +0000
Subject: [M3devel] m3cc -enable-checking=all
In-Reply-To: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>
References: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>
Message-ID: <COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>


static void
m3cg_and (void)
{
? MTYPE (t);

? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t),
???????????????????????????? EXPR_REF (-2), EXPR_REF (-1));
? EXPR_POP ();
}


Why do we make the result unsigned?

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Mon, 31 May 2010 08:44:27 +0000
> Subject: [M3devel] m3cc -enable-checking=all
>
>
>       Configure = Configure & " -enable-checking=all"
>
>
> enables a bunch of extra checks.
> That fail.
> With the current 4.3 backend.
> I'm going to look into some/all of this.
>
>
> .1079 = D.1078 & 1
> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
> word_64
>
> int_64
>
> int_64
>
> D.1101 = D.1100 & 1
> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
> word_64
>
> int_64
>
> int_64
>
> D.1121 = D.1120 & 1
> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
> word_64
>
>
> I think this might be one and only one problem.
> The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.
>
> Probably positive constants that fit in the signed type of the same size shouldn't fail.
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Mon May 31 12:32:43 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 10:32:43 +0000
Subject: [M3devel] m3cc -enable-checking=all
In-Reply-To: <COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
References: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>,
	<COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
Message-ID: <COL101-W1AB0D899A46A9622B7612E6EE0@phx.gbl>


-enable_checking=all does find more serious seeming stuff once the noise of int & int => word is removed:


static void
m3cg_pop (void)
{
? UNUSED_MTYPE (t);

? if (TREE_SIDE_EFFECTS (t))
??? add_stmt (EXPR_REF (-1));
? EXPR_POP ();
}


intent was presumably:

static void
m3cg_pop (void)
{
? UNUSED_MTYPE (t);
? tree a = EXPR_REF (-1);

? if (TREE_SIDE_EFFECTS (a))
??? add_stmt (a);
? EXPR_POP ();
}

alas..
introduced I think by rev 1.18 in 2006.
Previously we always set side_effects.


?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Mon, 31 May 2010 09:50:59 +0000
> Subject: Re: [M3devel] m3cc -enable-checking=all
>
>
> static void
> m3cg_and (void)
> {
>   MTYPE (t);
>
>   EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t),
>                              EXPR_REF (-2), EXPR_REF (-1));
>   EXPR_POP ();
> }
>
>
> Why do we make the result unsigned?
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Mon, 31 May 2010 08:44:27 +0000
>> Subject: [M3devel] m3cc -enable-checking=all
>>
>>
>> Configure = Configure & " -enable-checking=all"
>>
>>
>> enables a bunch of extra checks.
>> That fail.
>> With the current 4.3 backend.
>> I'm going to look into some/all of this.
>>
>>
>> .1079 = D.1078 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>> D.1101 = D.1100 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>> D.1121 = D.1120 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>>
>>
>> I think this might be one and only one problem.
>> The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.
>>
>> Probably positive constants that fit in the signed type of the same size shouldn't fail.
>>
>> - Jay
>>
>>
>
 		 	   		  

From jay.krell at cornell.edu  Mon May 31 12:57:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 31 May 2010 10:57:24 +0000
Subject: [M3devel] m3cc/configure -enable-checks=all non-trivial conversion
 at assignment
Message-ID: <COL101-W72E70FC74CFED51C30F64E6EE0@phx.gbl>


configure -enable-checks=all

../src/M3FP.m3:48: error: non-trivial conversion at assignment
word_64
int_64

????? error ("non-trivial conversion at assignment");
????? debug_generic_expr (TREE_TYPE (lhs));
????? debug_generic_expr (TREE_TYPE (rhs));
????? return true;


gcc doesn't like conversion from word64 to int64.

PROCEDURE ExtendByInt (READONLY a: T;? i: Int): T = (* line 48 *)
? VAR buf: NChars;
? BEGIN
??? FOR x := FIRST (buf) TO LAST (buf) DO
????? buf [x] := VAL (Word.And (i, 16_ff), CHAR);
????? i := Word.Shift (i, -8);? (* line 53 *)
??? END;
??? RETURN Fingerprint.FromChars (buf, a);
? END ExtendByInt;


The line is probably the one with the shift.
Int here is ???? Int = BITS 32 FOR [-16_7fffffff - 1 .. 16_7fffffff];

Presumably we should just build a cast?

I'm guessing the problem is:

(180) set_source_line
? source line?? 53
(181) load
? type:int32
? type:int64?? 
? m3cg_load (M3_ENQ7Kn_i): offset 0x0, convert int32 -> int64
(182) load_integer
? type:int64
? integer i:0xfe n_bytes:0x1 0x00000000000000008 sign -1
(183) shift
? type:word64? <== 
(184) import_procedure
? type:void
? procedure:RTHooks__ReportFault nparams:0x2 rettype:void
(185) declare_param
? type:addr
? param M3_AJWxb1_module type 0xb typeid 0x8402063 bytesize 0x40 alignment 0x40 in_memory 0x0 up_level 0x0
? mode 0x11 (DImode)
(186) declare_param
? type:int64
? param M3_AcxOUs_info type 0x7 typeid 0x195c2a74 bytesize 0x40 alignment 0x40 in_memory 0x0 up_level 0x0
? mode 0x11 (DImode)
(187) set_runtime_proc
(188) check_range
? type:int64
? integer i:0xfa n_bytes:0x4 0x00000000080000000 sign -1
? integer i:0xfb n_bytes:0x4 0x0000000007fffffff sign 1
? check range type 0x7 code 0x1
? declare_fault_proc: type is 0x11 (DImode)
(189) store
? type:int64? <==
? type:int32
? store (M3_ENQ7Kn_i) offset 0x0 src_t int64 dst_t int32
(190) set_source_line
?

The line numbers don't seem to be reported correctly -- we just get the first line of the function.

I don't think this is a serious problem, but probably here:

static void
m3cg_shift (void)
{
? MTYPE (t);

? tree n = declare_temp (t_int);
? tree x = declare_temp (t);

? gcc_assert (INTEGRAL_TYPE_P (t));

? add_stmt (m3_build2 (MODIFY_EXPR, t_int, n, EXPR_REF(-1)));
? add_stmt (m3_build2 (MODIFY_EXPR, t, x, EXPR_REF(-2)));


We should cast 1) assert t is unsigned and 2 ) cast x to it.

I will look into why we don't accidentally ever do arithmetic shift, as gcc does overload the same operand based on type:

/* Shift operations for shift and rotate.
?? Shift means logical shift if done on an
?? unsigned type, arithmetic shift if done on a signed type.
?? The second operand is the number of bits to
?? shift by; it need not be the same type as the first operand and result.
?? Note that the result is undefined if the second operand is larger
?? than or equal to the first operand's type size.? */
DEFTREECODE (LSHIFT_EXPR, "lshift_expr", tcc_binary, 2)
DEFTREECODE (RSHIFT_EXPR, "rshift_expr", tcc_binary, 2)
DEFTREECODE (LROTATE_EXPR, "lrotate_expr", tcc_binary, 2)
DEFTREECODE (RROTATE_EXPR, "rrotate_expr", tcc_binary, 2)


er. actually the problem is on output not input?
shift => word64
but then we do int64 => int32 conversion of the result.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon May 31 19:52:27 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 31 May 2010 13:52:27 -0400
Subject: [M3devel] m3cc -enable-checking=all
In-Reply-To: <COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
References: <COL101-W2822121BD934CC79DB2B68E6EE0@phx.gbl>
	<COL101-W3A654CF60A36E80DAF4C0E6EE0@phx.gbl>
Message-ID: <795CF2DA-5382-4A83-8536-E51FB3343724@cs.purdue.edu>

Good question.  Shouldn't it be type t?

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 31 May 2010, at 05:50, Jay K wrote:

> 
> static void
> m3cg_and (void)
> {
>   MTYPE (t);
> 
>   EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, m3_unsigned_type (t),
>                              EXPR_REF (-2), EXPR_REF (-1));
>   EXPR_POP ();
> }
> 
> 
> Why do we make the result unsigned?
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Mon, 31 May 2010 08:44:27 +0000
>> Subject: [M3devel] m3cc -enable-checking=all
>> 
>> 
>>      Configure = Configure & " -enable-checking=all"
>> 
>> 
>> enables a bunch of extra checks.
>> That fail.
>> With the current 4.3 backend.
>> I'm going to look into some/all of this.
>> 
>> 
>> .1079 = D.1078 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>> 
>> int_64
>> 
>> int_64
>> 
>> D.1101 = D.1100 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>> 
>> int_64
>> 
>> int_64
>> 
>> D.1121 = D.1120 & 1
>> ../src/ConnectRdWr.m3:35: error: type mismatch in binary expression
>> word_64
>> 
>> 
>> I think this might be one and only one problem.
>> The "tagged reference" checking using signed 1 instead of unsigned 1 in anding with the address.
>> 
>> Probably positive constants that fit in the signed type of the same size shouldn't fail.
>> 
>> - Jay
>> 
>> 
> 		 	   		  

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